Bug 17280 - breakpoint problem on aarch64 (in qemu full-system emulation): SIGTRAP/SIGSEGV in debugged program
Summary: breakpoint problem on aarch64 (in qemu full-system emulation): SIGTRAP/SIGSEG...
Status: RESOLVED INVALID
Alias: None
Product: gdb
Classification: Unclassified
Component: breakpoints (show other bugs)
Version: HEAD
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-08-16 18:03 UTC by Akos Kiss
Modified: 2014-08-18 12:14 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Akos Kiss 2014-08-16 18:03:28 UTC
I'm running an aarch64 Ubuntu 14.04.1 LTS VM on qemu. Rootfs, initrd, and kernel are all as available from Ubuntu websites, nothing was customized, reconfigured, or rebuilt. The gdb that installs with "apt-get install gdb" identifies itself as "GNU gdb (Ubuntu 7.7-0ubuntu3.1) 7.7". Using this gdb, debugging even the simplest Hello World application fails:

$ gdb helloworld
Reading symbols from helloworld...done.
(gdb) run
Starting program: /home/akiss/devel/test/helloworld 
Program received signal SIGTRAP, Trace/breakpoint trap.
_dl_debug_initialize (ldbase=1, ns=1016) at dl-debug.c:47
47	dl-debug.c: No such file or directory.
(gdb) bt
#0  _dl_debug_initialize (ldbase=1, ns=1016) at dl-debug.c:47
#1  0x0000007fb7fd5cf4 in dl_main (phdr=<optimized out>, phnum=<optimized out>, 
    user_entry=<optimized out>, auxv=<optimized out>) at rtld.c:1592
#2  0x0000007fb7fe63a0 in _dl_sysdep_start (start_argptr=start_argptr@entry=0x7ffffff570, 
    dl_main=dl_main@entry=0x7fb7fd44c4 <dl_main>) at ../elf/dl-sysdep.c:249
#3  0x0000007fb7fd71f0 in _dl_start_final (arg=arg@entry=0x7ffffff570, 
    info=info@entry=0x7ffffff108) at rtld.c:332
#4  0x0000007fb7fd7478 in _dl_start (arg=0x7ffffff570) at rtld.c:560
#5  0x0000007fb7fd3f88 in _start () from /lib/ld-linux-aarch64.so.1
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) mt i br
Num     Type           Disp Enb Address            What
-1      shlib events   keep y   0x0000007fb7fe0a8c <__GI__dl_debug_state> inf 1
(gdb) cont
Continuing.
Program received signal SIGSEGV, Segmentation fault.
_dl_debug_initialize (ldbase=1, ns=1016) at dl-debug.c:55

After that, I cloned the repo and built gdb natively on the vm with default configuration options. Running the same Hello World application failed with a slightly different but reminiscent error:

$ ~/local/bin/gdb helloworld 
GNU gdb (GDB) 7.8.50.20140815-cvs
This GDB was configured as "aarch64-unknown-linux-gnu".
Reading symbols from helloworld...done.
(gdb) run
Starting program: /home/akiss/devel/test/helloworld 
Program received signal SIGTRAP, Trace/breakpoint trap.
0x0000007fb7fe0a90 in ?? () from /lib/ld-linux-aarch64.so.1
(gdb) bt
#0  0x0000007fb7fe0a90 in ?? () from /lib/ld-linux-aarch64.so.1
#1  0x0000007fb7ffe000 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
(gdb) mt i br
Num     Type           Disp Enb Address            What
-1      shlib events   keep y   0x0000007fb7fe0a8c <_dl_debug_state> inf 1
(gdb) cont
Continuing.
Program received signal SIGSEGV, Segmentation fault.
0x0000007fb7fe0ab0 in ?? () from /lib/ld-linux-aarch64.so.1

Discussions at #gdb speculated about the pc "not backing up one" when hitting a breakpoint. So it was suggested (by Doug Evans) to experiment with adding "set_gdbarch_decr_pc_after_break (gdbarch, 4);" to gdb/aarch64-tdep.c (aarch64_gdbarch_init). That solved the initial problem, i.e., all the apps ran inside gdb, but then a new error appeared. Even a single breakpoint at main() causes a segfault.

$ ~/local/bin/gdb helloworld 
GNU gdb (GDB) 7.8.50.20140815-cvs
Reading symbols from helloworld...done.
(gdb) b main
Breakpoint 1 at 0x4005d8: file hellofarm.cpp, line 4.
(gdb) run
Starting program: /home/akiss/devel/tesz/helloworld 
Program received signal SIGSEGV, Segmentation fault.
0x0000007fb7f061e0 in ?? ()
(gdb) info sharedlibrary 
From                To                  Syms Read   Shared Object Library
0x0000007fb7fd3b40  0x0000007fb7fe9b10  Yes         /lib/ld-linux-aarch64.so.1
0x0000007fb7ea7880  0x0000007fb7f8a6c8  No          /lib/aarch64-linux-gnu/libc.so.6
(gdb) bt
#0  0x0000007fb7f061e0 in ?? () from /lib/aarch64-linux-gnu/libc.so.6
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) mt i br
Num     Type           Disp Enb Address            What
1       breakpoint     keep y   0x00000000004005d8 in main() at hellofarm.cpp:4 inf 1
-1      shlib events   keep y   0x0000007fb7fe0a8c <__GI__dl_debug_state> inf 1
Comment 1 Akos Kiss 2014-08-18 12:14:35 UTC
All problems turned out to be caused by qemu limitations:
- The pc being off by 4 was an incorrect implementation of the BRK instruction.
- All the remaining issues were caused by qemu not implementing support for single-stepping.

http://lists.nongnu.org/archive/html/qemu-devel/2014-08/msg02909.html

With the patches from the qemu-devel mailing list applied, even the ubuntu-packaged gdb works correctly.