[Bug gdb/30866] New: [gdb/symtab] symbolic links to debuginfo not followed when debugging from outside container

["vries at gcc dot gnu.org" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=30866

            Bug ID: 30866
           Summary: [gdb/symtab] symbolic links to debuginfo not followed
                    when debugging from outside container
           Product: gdb
           Version: HEAD
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: gdb
          Assignee: unassigned at sourceware dot org
          Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

Consider the following session:
...
$ podman pull docker.io/opensuse/leap
$ podman run -dt --pid host docker.io/opensuse/leap
<container-id>
$ podman attach <container-id>
...
and:
...
$ podman exec -it <container-id> bash
...
to get two shells.

Install emacs, gcc, gdb, sysvinit-tools using "zypper install".

Create a symlink /lib64-symlink -> /lib64.

Edit /etc/zypp/repos.d to enable debug repositories (open files with debug in
name, replace 0 by 1 in enabled=0 line).

Install glibc-debuginfo.

Create test.c:
...
#include <unistd.h>
#include <stdio.h>

static volatile int hello = 0;

int
main (void)
{
  while (1)
    {
      sleep (1);
      if (hello)
        printf ("hello");
    }

  return 0;
}
...

And compile it:
...
$ gcc test.c -g -Wl,-rpath,/lib64-symlink
...

Run it in one shell, and find the pid and attach (using system gdb) in another:
...
$ gdb -iex "set debug separate-debug-file on" -p $(pidof a.out)
  ...
Looking for separate debug info (build-id) for /lib64-symlink/libc.so.6
  Trying
/usr/lib/debug/.build-id/76/7aa1e4d4fc7c106971b202b6b00e92f47411dc.debug...
yes!
Reading symbols from
/usr/lib/debug/lib64/libc-2.31.so-2.31-150300.52.2.x86_64.debug...
...

Note that gdb manages to follow the symlink of the .build-id file.

Likewise, if we move .build-id to .id-build, we get instead:
...
Looking for separate debug info (debug link) for /lib64-symlink/libc.so.6
  Trying /lib64/libc-2.31.so-2.31-150300.52.2.x86_64.debug... no, unable to
open.
  Trying /lib64/.debug/libc-2.31.so-2.31-150300.52.2.x86_64.debug... no, unable
to open.
  Trying /usr/lib/debug//lib64/libc-2.31.so-2.31-150300.52.2.x86_64.debug...
yes!
Reading symbols from
/usr/lib/debug//lib64/libc-2.31.so-2.31-150300.52.2.x86_64.debug...
...

Note that again gdb manages to follow a symlink.

Now try from outside the container (using current gdb build from source) and
sudo (and re-enable .build-id):
...
Looking for separate debug info (build-id) for target:/lib64-symlink/libc.so.6
  Trying
/usr/lib/debug/.build-id/76/7aa1e4d4fc7c106971b202b6b00e92f47411dc.debug... no,
unable to compute real path
  Trying
target:/usr/lib/debug/.build-id/76/7aa1e4d4fc7c106971b202b6b00e92f47411dc.debug...
yes!
Reading symbols from
target:/usr/lib/debug/.build-id/76/7aa1e4d4fc7c106971b202b6b00e92f47411dc.debug...
...

Note that in this case, we didn't follow the symlink.  That is not a problem,
the file system handling follows the symlink and the file is found.

Again, move .build-id to .id-build:
...
Looking for separate debug info (debug link) for
target:/lib64-symlink/libc.so.6
  Trying target:/lib64-symlink/libc-2.31.so-2.31-150300.52.2.x86_64.debug...
no, unable to open.
  Trying
target:/lib64-symlink/.debug/libc-2.31.so-2.31-150300.52.2.x86_64.debug... no,
unable to open.
  Trying
target:/usr/lib/debug//lib64-symlink/libc-2.31.so-2.31-150300.52.2.x86_64.debug...
no, unable to open.
  Trying
target:/usr/lib/debug/lib64-symlink//libc-2.31.so-2.31-150300.52.2.x86_64.debug...
no, unable to open.
(No debugging symbols found in target:/lib64-symlink/libc.so.6)
...

Note that in this case again, we didn't follow the symlink, but this time
resulting in not finding the debuginfo file.

-- 
You are receiving this mail because:
You are on the CC list for the bug.