Question about backtraces through signal handlers for aarch64 ILP32 support

[Steve Ellcey <sellcey at caviumnetworks dot com>]

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