From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id D0544385ED69; Wed, 29 May 2024 11:08:21 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org D0544385ED69 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1716980901; bh=W9/HP6BfaxjSbpcT5SMfHPE6v25Iyzy/jn5082AJhVQ=; h=From:To:Subject:Date:From; b=qLRZX1Jde2kAD8ZTXC7oONkY/+Kr67XC0NccJ0W3VZcQT2y4DLZ3KkyZHi2ecDwlf 9Xb4XGBqtL/AYTY5RkjCrbzW36uzBfy3YsWsRZZFq65SpwOMyaCOy6kRv52kVQuul4 eQUC7JmCpf4o90PlYkkOfO73jTd/+huKCkow0ULo= From: "vries at gcc dot gnu.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 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gdb X-Bugzilla-Component: tdep X-Bugzilla-Version: HEAD X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: vries at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter target_milestone Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://sourceware.org/bugzilla/show_bug.cgi?id=3D31817 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=20 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 t= humb 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= =20=20=20=20=20=20=20 however it's spelled in your particular system) is ARM or Thumb.= =20=20=20=20=20=20=20 That knowledge is encoded in the address, if it's Thumb the low bi= t=20=20=20=20 is 1. However, we've stripped that info above and it's not clear= =20=20=20=20=20=20 what all the consequences are of passing a non-addr_bits_remove'd= =20=20=20=20=20=20 address to svr4_create_solib_event_breakpoints. The call to=20=20= =20=20=20=20=20=20=20=20=20 find_pc_section verifies we know about the address and have some= =20=20=20=20=20=20=20 hope of computing the right kind of breakpoint to use (via=20=20= =20=20=20=20=20=20=20=20=20=20=20 symbol info). It does mean that GDB needs to be pointed at a=20= =20=20=20=20=20=20=20=20=20 non-stripped version of the dynamic linker in order to obtain=20= =20=20=20=20=20=20=20=20=20 information it already knows about. Sigh. */ os =3D find_pc_section (sym_addr); if (os !=3D 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 e= ven 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 !=3D 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 =3D 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 =3D gdbarch_convert_from_func_ptr_addr + (current_inferior ()->arch (), sym_addr, + tmp_bfd_target.get ()); + + struct obj_section *os =3D find_pc_section (sym_addr); + if (os =3D=3D nullptr) + sym_addr =3D 0; + } if (sym_addr !=3D 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 sh= ould 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. --=20 You are receiving this mail because: You are on the CC list for the bug.=