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

[Luis Machado <lgustavo at codesourcery dot com>]

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.