Re: [PATCH v3 3/3] Aarch64: Fix segfault when casting dummy calls

[Alan Hayward <Alan dot Hayward at arm dot com>]

> On 29 Oct 2018, at 12:38, Pedro Alves <palves@redhat.com> wrote:
> 
> On 10/29/2018 11:58 AM, Alan Hayward wrote:
>> 
>> 
>>> On 24 Oct 2018, at 16:14, Pedro Alves <palves@redhat.com> wrote:
>>> 
>>>> 
>>>>> 
>>>>> And what does "to ensure FUNC resolving" mean too, btw?
>>>>> AFAICT, the only reason to use a shared library is to
>>>>> compile it with or without debug information, right?
>>>>> Come to think of it, you could instead eliminate the
>>>>> shared library and compile a separate .o file instead, right?
>>>>> That would simplify the testcase a bit and expose it to more
>>>>> targets.
>>>>> 
>>>> 
>>>> I could only get the bug to expose itself when using a .so
>>>> 
>>>> If I do the following using current HEAD then the bug is not present:
>>>> 
>>>> g++ -c condbreak-solib-main.cc -o condbreak-solib-main.o -fno-inline
>>>> g++ -c condbreak-solib-lib.cc -o condbreak-solib-lib.o -fno-inline
>>>> g++ condbreak-solib-main.o condbreak-solib-lib.o
>>>> 
>>>> It causes the type of the return value to be detected as
>>>> TYPE_CODE_PTR->TYPE_CODE_INT.
>>> 
>>> Huh.  That's really strange.  Where is that pointer coming from?
>>> 
>>> What does "ptype cmp3" say for you?
>>> 
>>> (gdb) b foo if (int)cmp3("abc") == 1
>>> Breakpoint 1 at 0x40048b
>>> (gdb) ptype cmp3
>>> type = <unknown return type> ()
>>> (gdb) whatis cmp3
>>> type = <text variable, no debug info>
>>> 
>> 
>> Yes, I get the same.
>> 
>> Sounds to me like there might still be an issue in gdb? Or at least
>> a difference in the way the type is calculated.
>> This on it’s own is still a good fix, so I’ll send a new version.
> 
> I think we should learn the answer to the "where is that pointer
> coming from" question.  I'm really not understanding why the
> shared library makes a difference.
> 
>> 
>> 
>>> I wonder if what you're looking at is actually the malloc call?
>>> GDB will call malloc to allocate space for the "abc" string in
>>> the inferior.  Look at the backtrace, see where the call is coming
>>> from.
>> 
>> 
>> With the nodebug and debug shared library version:
>> (I need to run to main before I can set breakpoint on cmp3, otherwise
>> "Function "cmp3" not defined.”)
>> 
>> But with all versions, when stopped at cmp3, I get:
>> (gdb) bt
>> #0  0x00000000004005d4 in cmp3(char const*) ()
>> #1  <function called from gdb>
>> #2  0x00000000004005a4 in foo() ()
>> #3  0x00000000004005bc in main ()
> 
> 
> That's a backtrace in the inferior.  I meant instead for you to set
> a breakpoint on gdb's aarch64_push_dummy_call, figure out where the
> TYPE_CODE_PTR->TYPE_CODE_INT pointer comes from.  
> With "b foo if (int)cmp3("abc") == 1", gdb will do two
> infcalls, one malloc call to allocate space for "abc"
> string, and then the call to cmp3.
> 

A-ha! Now I understand why I get two calls into _push_dummy_call.

So to answer your question, the TYPE_CODE_PTR->TYPE_CODE_INT is the malloc call.

Then the next call to _push_dummy_call has a return type of 0, as expected.
This doesn’t segfault because it goes into language_pass_by_reference which
routes to default_pass_by_reference. The same as the C shared library version.


I’ve updated the test so it does {c,c++}*{debug nodebug}.
I can also update it to do both shared lib and non shared lib too. That should
cover everything.


Alan.