Question about backtraces through signal handlers for aarch64 ILP32 support

Question about backtraces through signal handlers for aarch64 ILP32 support

[Steve Ellcey]

I am working on supporting gdb on aarch64 in ILP32 mode but am not that
familiar with gdb and was wondering if anyone could give me some ideas
on where to look for a problem I am seeing.

I run the test case 'gdb.base/sigstep' in gdb by hand and do the initial
commands that that testsuite does:

	break main
	run
	break handler
	continue
	bt

In LP64 mode, I get this backtrace:

#0  handler (sig=26)
    at /home/ubuntu/sellcey/gdb-ilp32/obj-64/binutils/gdb/testsuite/../../../..
/src/binutils-gdb/gdb/testsuite/gdb.base/sigstep.c:35
#1  <signal handler called>
#2  0x00000000004008cc in main ()
    at /home/ubuntu/sellcey/gdb-ilp32/obj-64/binutils/gdb/testsuite/../../../..
/src/binutils-gdb/gdb/testsuite/gdb.base/sigstep.c:87

But in ILP32 mode, I get this backtrace:

#0  handler (sig=26)
    at /home/ubuntu/sellcey/gdb-ilp32/obj-32/binutils/gdb/testsuite/../../../..
/src/binutils-gdb/gdb/testsuite/gdb.base/sigstep.c:35
#1  <signal handler called>
#2  0x00000000 in ?? ()
#3  0x00400740 in main ()
    at /home/ubuntu/sellcey/gdb-ilp32/obj-32/binutils/gdb/testsuite/../../../..
/src/binutils-gdb/gdb/testsuite/gdb.base/sigstep.c:87


I think the backtrace for ILP32 does not match what is expected because
it has the extra entry in it (#2 with no name or location).  I am not sure
if that is a real frame that the test needs to expect or just an error in
how gdb is reading the frame information.

Normal backtraces seem to be working fine, the majority of ILP32 failures
I get in gdb.base (that don't also happen in LP64 mode) are tests with 'sig'
in their name like sigstep.

Any ideas on where to look or what to look for?

Steve Ellcey
sellcey@cavium.com

Re: Question about backtraces through signal handlers for aarch64 ILP32 support

[Luis Machado]

On 02/27/2017 06:26 PM, Steve Ellcey wrote:
> I am working on supporting gdb on aarch64 in ILP32 mode but am not that
> familiar with gdb and was wondering if anyone could give me some ideas
> on where to look for a problem I am seeing.
>
> I run the test case 'gdb.base/sigstep' in gdb by hand and do the initial
> commands that that testsuite does:
>
> 	break main
> 	run
> 	break handler
> 	continue
> 	bt
>
> In LP64 mode, I get this backtrace:
>
> #0  handler (sig=26)
>     at /home/ubuntu/sellcey/gdb-ilp32/obj-64/binutils/gdb/testsuite/../../../..
> /src/binutils-gdb/gdb/testsuite/gdb.base/sigstep.c:35
> #1  <signal handler called>
> #2  0x00000000004008cc in main ()
>     at /home/ubuntu/sellcey/gdb-ilp32/obj-64/binutils/gdb/testsuite/../../../..
> /src/binutils-gdb/gdb/testsuite/gdb.base/sigstep.c:87
>
> But in ILP32 mode, I get this backtrace:
>
> #0  handler (sig=26)
>     at /home/ubuntu/sellcey/gdb-ilp32/obj-32/binutils/gdb/testsuite/../../../..
> /src/binutils-gdb/gdb/testsuite/gdb.base/sigstep.c:35
> #1  <signal handler called>
> #2  0x00000000 in ?? ()
> #3  0x00400740 in main ()
>     at /home/ubuntu/sellcey/gdb-ilp32/obj-32/binutils/gdb/testsuite/../../../..
> /src/binutils-gdb/gdb/testsuite/gdb.base/sigstep.c:87
>
>
> I think the backtrace for ILP32 does not match what is expected because
> it has the extra entry in it (#2 with no name or location).  I am not sure
> if that is a real frame that the test needs to expect or just an error in
> how gdb is reading the frame information.

Not a real entry AFAICS.

>
> Normal backtraces seem to be working fine, the majority of ILP32 failures
> I get in gdb.base (that don't also happen in LP64 mode) are tests with 'sig'
> in their name like sigstep.
>
> Any ideas on where to look or what to look for?

That extra frame indicates gdb is getting confused when extracting 
register state from the signal frame and creates a spurious frame at 
0x0. Maybe gdb is finding a frame pointer that points to 0x0 and should 
instead point to 0x00400740 (main)? Tracking that down may help figure 
it out.

Otherwise the backtrace looks sane.

Re: Question about backtraces through signal handlers for aarch64 ILP32 support

[Yao Qi]

Luis Machado <lgustavo@codesourcery.com> writes:

>> Normal backtraces seem to be working fine, the majority of ILP32 failures
>> I get in gdb.base (that don't also happen in LP64 mode) are tests with 'sig'
>> in their name like sigstep.
>>
>> Any ideas on where to look or what to look for?
>
> That extra frame indicates gdb is getting confused when extracting
> register state from the signal frame and creates a spurious frame at
> 0x0. Maybe gdb is finding a frame pointer that points to 0x0 and
> should instead point to 0x00400740 (main)? Tracking that down may help
> figure it out.

I think Luis is right.  From your log, I can see that sigframe is found,
and the right unwinder is used, but it gets the wrong value when it
unwinds stack.  Probably, you need to look at
aarch64-linux-tdep.c:aarch64_linux_sigframe_init and some macros defines
above.

-- 
Yao (齐尧)

Re: Question about backtraces through signal handlers for aarch64 ILP32 support

[Andreas Schwab]

On Feb 27 2017, Steve Ellcey <sellcey@caviumnetworks.com> wrote:

> Any ideas on where to look or what to look for?

Most likely the signal frame parser needs to be updated to properly
handle ILP32, see aarch64-linux-tdep.c:aarch64_linux_sigframe_init.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."