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.

             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: 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).