public inbox for gdb-prs@sourceware.org help / color / mirror / Atom feed
From: "vries at gcc dot gnu.org" <sourceware-bugzilla@sourceware.org> To: gdb-prs@sourceware.org Subject: [Bug tdep/31817] New: [gdb/tdep, arm] thumb ld.so and "set auto-solib-add off" don't work well together Date: Wed, 29 May 2024 11:08:21 +0000 [thread overview] Message-ID: <bug-31817-4717@http.sourceware.org/bugzilla/> (raw) https://sourceware.org/bugzilla/show_bug.cgi?id=31817 Bug ID: 31817 Summary: [gdb/tdep, arm] thumb ld.so and "set auto-solib-add off" don't work well together Product: gdb Version: HEAD Status: NEW Severity: normal Priority: P2 Component: tdep Assignee: unassigned at sourceware dot org Reporter: vries at gcc dot gnu.org Target Milestone: --- Consider a hello world test-case: ... $ gcc hello.c ... Which runs fine without gdb: ... $ ./a.out hello ... And runs fine with gdb: ... $ gdb -q -batch a.out -ex run [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1". hello [Inferior 1 (process 2227847) exited normally] ... Now, let's try that with "set auto-solib-add off": ... $ gdb -q -batch -iex "set auto-solib-add off" a.out -ex "run" Program received signal SIGSEGV, Segmentation fault. 0xf7fd2646 in ?? () from /lib/ld-linux-armhf.so.3 ... So, what happened here? We get a bit more info like this: ... $ gdb -q -batch -iex "set auto-solib-add off" a.out \ -ex starti \ -ex "maint info break" \ -ex continue Program stopped. 0xf7fe1564 in ?? () from /lib/ld-linux-armhf.so.3 Num Type Disp Enb Address What -1 shlib events keep y 0xf7fd2660 inf 1 -1.1 y 0xf7fd2660 inf 1 Program received signal SIGSEGV, Segmentation fault. 0xf7fd2646 in ?? () from /lib/ld-linux-armhf.so.3 ... Only one internal breakpoint was installed, the shlib events one. Somehow, even in absence of symbol info, the address of _dl_debug_state@@GLIBC_PRIVATE is found. But setting a breakpoint on it requires knowing whether this is an arm or thumb function. There's a large comment about this in solib-svr4.c:enable_break: ... On ARM we need to know whether the ISA of rtld_db_dlactivity (or however it's spelled in your particular system) is ARM or Thumb. That knowledge is encoded in the address, if it's Thumb the low bit is 1. However, we've stripped that info above and it's not clear what all the consequences are of passing a non-addr_bits_remove'd address to svr4_create_solib_event_breakpoints. The call to find_pc_section verifies we know about the address and have some hope of computing the right kind of breakpoint to use (via symbol info). It does mean that GDB needs to be pointed at a non-stripped version of the dynamic linker in order to obtain information it already knows about. Sigh. */ os = find_pc_section (sym_addr); if (os != NULL) ... That code is not triggered however, because at that point sym_addr is still 0. Reading through enable_break, it becomes clear that we manage to find the address of the address of _dl_debug_state@@GLIBC_PRIVATE by peeking into bfd symbols. I'm not sure it that's allowed for "set auto-solib-add off", or even whether the bfd symbols should be there. Anyway, by replicating the same check: ... diff --git a/gdb/solib-svr4.c b/gdb/solib-svr4.c index 1d4a50568d7..bbd07dab7e1 100644 --- a/gdb/solib-svr4.c +++ b/gdb/solib-svr4.c @@ -2452,12 +2452,18 @@ enable_break (struct svr4_info *info, int from_tty) } if (sym_addr != 0) - /* Convert 'sym_addr' from a function pointer to an address. - Because we pass tmp_bfd_target instead of the current - target, this will always produce an unrelocated value. */ - sym_addr = gdbarch_convert_from_func_ptr_addr - (current_inferior ()->arch (), sym_addr, - tmp_bfd_target.get ()); + { + /* Convert 'sym_addr' from a function pointer to an address. + Because we pass tmp_bfd_target instead of the current + target, this will always produce an unrelocated value. */ + sym_addr = gdbarch_convert_from_func_ptr_addr + (current_inferior ()->arch (), sym_addr, + tmp_bfd_target.get ()); + + struct obj_section *os = find_pc_section (sym_addr); + if (os == nullptr) + sym_addr = 0; + } if (sym_addr != 0) { ... we get: ... $ gdb -q -batch -iex "set auto-solib-add off" a.out -ex run warning: Unable to find dynamic linker breakpoint function. GDB will be unable to debug shared library initializers and track explicitly loaded dynamic code. [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1". hello [Inferior 1 (process 2230337) exited normally] ... Regardless of this PR, and it being fixed or not, we use "set auto-solib-add off" in the testsuite to work around certain symbol clash issues, and we should probably try to solve that in another way, because some targets are just not designed to work well without symbol info for some critical libs. -- You are receiving this mail because: You are on the CC list for the bug.
next reply other threads:[~2024-05-29 11:08 UTC|newest] Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top 2024-05-29 11:08 vries at gcc dot gnu.org [this message] 2024-06-06 12:41 ` [Bug tdep/31817] " vries at gcc dot gnu.org 2024-06-06 13:25 ` vries at gcc dot gnu.org 2024-06-07 14:39 ` vries at gcc dot gnu.org
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-31817-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: linkBe 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).