Question about backtraces through signal handlers for aarch64 ILP32 support

Luis Machado lgustavo@codesourcery.com
Tue Feb 28 00:36:00 GMT 2017


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.



More information about the Gdb mailing list