public inbox for gdb-prs@sourceware.org
help / color / mirror / Atom feed
From: "akiss at inf dot u-szeged.hu" <sourceware-bugzilla@sourceware.org>
To: gdb-prs@sourceware.org
Subject: [Bug breakpoints/17280] New: breakpoint problem on aarch64 (in qemu full-system emulation): SIGTRAP/SIGSEGV in debugged program
Date: Sat, 16 Aug 2014 18:03:00 -0000 [thread overview]
Message-ID: <bug-17280-4717@http.sourceware.org/bugzilla/> (raw)
https://sourceware.org/bugzilla/show_bug.cgi?id=17280
Bug ID: 17280
Summary: breakpoint problem on aarch64 (in qemu full-system
emulation): SIGTRAP/SIGSEGV in debugged program
Product: gdb
Version: HEAD
Status: NEW
Severity: normal
Priority: P2
Component: breakpoints
Assignee: unassigned at sourceware dot org
Reporter: akiss at inf dot u-szeged.hu
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
--
You are receiving this mail because:
You are on the CC list for the bug.
next reply other threads:[~2014-08-16 18:03 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-16 18:03 akiss at inf dot u-szeged.hu [this message]
2014-08-16 18:06 ` [Bug breakpoints/17280] " akiss at inf dot u-szeged.hu
2014-08-18 12:14 ` akiss at inf dot u-szeged.hu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=bug-17280-4717@http.sourceware.org/bugzilla/ \
--to=sourceware-bugzilla@sourceware.org \
--cc=gdb-prs@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).