[Bug gdb/29181] New: Support dlmopen and LD_AUDIT private namespaces

[Bug gdb/29181] New: Support dlmopen and LD_AUDIT private namespaces

[woodard at redhat dot com]

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

            Bug ID: 29181
           Summary: Support dlmopen and LD_AUDIT private namespaces
           Product: gdb
           Version: HEAD
            Status: NEW
          Severity: normal
          Priority: P2
         Component: gdb
          Assignee: unassigned at sourceware dot org
          Reporter: woodard at redhat dot com
  Target Milestone: ---

glibc 2.35 https://lists.gnu.org/archive/html/info-gnu/2022-02/msg00002.html
changed the debugger interface to support private namespaces:

* Bump r_version in the debugger interface to 2 and add a new field,
  r_next, support multiple namespaces.

glibc needs to be able find symbols within the objects in those namespaces.
There is an upstream patch pending which begins that process:
https://sourceware.org/pipermail/gdb-patches/2021-November/183498.html

The patch was discussed here:
https://sourceware.org/pipermail/gdb-patches/2022-March/186239.html and here:
https://sourceware.org/pipermail/gdb-patches/2022-April/187648.html

This is a good start but it overlooks many usability issues. I posted this:
https://sourceware.org/pipermail/gdb-patches/2022-May/189381.html

I also spent quite a while talking with the people asking for this feature and
compiled their GDB UI requests.

First of all there needs to be a way to have some way to associate a particular
library that was loaded by the dynamic linker into a private namespace vs one
that was loaded into a the default namespace. This is particularly important
because two versions of the same library may be loaded. e.g. libstdc++ So a
suggestion would be to put a number indicating the namespace in the list of
shared libraries with 0 being the default namespace. This would turn: 

(gdb) info shared
  From                To                  Syms Read   Shared Object Library
  0x00007ffff7fc8090  0x00007ffff7feea45  Yes        
/lib64/ld-linux-x86-64.so.2
  0x00007ffff7fb12a0  0x00007ffff7fb9022  Yes         ./auditlib.so
  0x00007ffff7df73f0  0x00007ffff7eff532  Yes         /lib64/libstdc++.so.6
  0x00007ffff7c873b0  0x00007ffff7cf8b58  Yes         /lib64/libm.so.6
  0x00007ffff7c5a670  0x00007ffff7c70c05  Yes         /lib64/libgcc_s.so.1
  0x00007ffff7a82740  0x00007ffff7bf371d  Yes         /lib64/libc.so.6
  0x00007ffff7fc8090  0x00007ffff7feea45  Yes        
/lib64/ld-linux-x86-64.so.2
  0x00007ffff777d740  0x00007ffff78ee71d  Yes         /lib64/libc.so.6

into something like this:

(gdb) info shared
  From                To                  Syms Read   NS        Shared Object
Library
  0x00007ffff7fc8090  0x00007ffff7feea45  Yes         1
/lib64/ld-linux-x86-64.so.2
  0x00007ffff7fb12a0  0x00007ffff7fb9022  Yes         1 ./auditlib.so
  0x00007ffff7df73f0  0x00007ffff7eff532  Yes         1 /lib64/libstdc++.so.6
  0x00007ffff7c873b0  0x00007ffff7cf8b58  Yes         0 /lib64/libm.so.6
  0x00007ffff7c5a670  0x00007ffff7c70c05  Yes         0 /lib64/libgcc_s.so.1
  0x00007ffff7a82740  0x00007ffff7bf371d  Yes         1 /lib64/libc.so.6
  0x00007ffff7fc8090  0x00007ffff7feea45  Yes         0
/lib64/ld-linux-x86-64.so.2
  0x00007ffff777d740  0x00007ffff78ee71d  Yes         0 /lib64/libc.so.6

It is important to be able to disambiguate symbols and target a particular
namespace. Since developers frequently use cut and paste, a particular request
is that the same syntax used by GDB to print a symbol should be accepted when a
user types it.

We had a long discussion about how to indicate this. We believe that:
1) prefixes are preferred over suffixes because some C++ function names can be
excessively long and visually picking it out of the function name can be
difficult.
2) Using the c++ nanmespace qualifier "::" could work but it could be confusing
when working with C++ code. If any other signifier is chosen, it should be
picked such that it doesn't interfere with operator precedence when typing
expressions. Braces may be a good suggestion. So the two suggestions are:

(gdb) print {3}my_function_in_namespace2(args…) + 7

or

(gdb) print 3::my_function_in_namespace2(args…) + 7

When listing breakpoints the namespace in which the breakpoint exists should be
listed when enumerating the breakpoints. 

Searching all the namespaces for symbols that match and setting breakpoints at
all of them is not a viable option. The teams that work on tools and the teams
that work on apps are different. The teams that work on tools are interested in
the tool themselves and while an app may be needed as a reproducer, it adds
noise to the debugging process if breakpoints are set in it as well. This
particular problem is particularly bad with C++ where there can be hundreds or
thousands of instantiations of inlined functions. 

Similarly backtraces need to denote when a particular symbol exists in private
namespace. Turning something like:
  (gdb) bt
  #0  doPrint (output=...) at auditlib.cpp:30
  #1  0x00007ffff7fb4cf0 in la_activity (cookie=<optimized out>, 
        flag=<optimized out>) at /usr/include/c++/11/bits/char_traits.h:357
  #2  0x00007ffff7fdf415 in _dl_audit_activity_map (l=l@entry=0x7ffff7ffe2a0, 
        action=action@entry=1) at dl-audit.c:33
  #3  0x00007ffff7fe6c98 in dl_main (phdr=<optimized out>, 
        phnum=<optimized out>, user_entry=<optimized out>, auxv=<optimized
out>)
        at rtld.c:1832
  #4  0x00007ffff7fe328f in _dl_sysdep_start (
        start_argptr=start_argptr@entry=0x7fffffffdbe0, 
        dl_main=dl_main@entry=0x7ffff7fe52a0 <dl_main>) at
../elf/dl-sysdep.c:256
  #5  0x00007ffff7fe503e in _dl_start_final (arg=0x7fffffffdbe0) at rtld.c:507
  #6  _dl_start (arg=0x7fffffffdbe0) at rtld.c:596
  #7  0x00007ffff7fe3e38 in _start () from /lib64/ld-linux-x86-64.so.2

into:

  (gdb) bt
  #0  {1}doPrint (output=...) at auditlib.cpp:30
  #1  0x00007ffff7fb4cf0 in {1}la_activity (cookie=<optimized out>, 
        flag=<optimized out>) at /usr/include/c++/11/bits/char_traits.h:357
  #2  0x00007ffff7fdf415 in _dl_audit_activity_map (l=l@entry=0x7ffff7ffe2a0, 
        action=action@entry=1) at dl-audit.c:33
  #3  0x00007ffff7fe6c98 in dl_main (phdr=<optimized out>, 
        phnum=<optimized out>, user_entry=<optimized out>, auxv=<optimized
out>)
        at rtld.c:1832
  #4  0x00007ffff7fe328f in _dl_sysdep_start (
        start_argptr=start_argptr@entry=0x7fffffffdbe0, 
        dl_main=dl_main@entry=0x7ffff7fe52a0 <dl_main>) at
../elf/dl-sysdep.c:256
  #5  0x00007ffff7fe503e in _dl_start_final (arg=0x7fffffffdbe0) at rtld.c:507
  #6  _dl_start (arg=0x7fffffffdbe0) at rtld.c:596
  #7  0x00007ffff7fe3e38 in _start () from /lib64/ld-linux-x86-64.so.2

One concern is that if an auditor crashes or causes a crash even before library
loading for the app has begun. The tool writers stress that they still need to
be able to get a backtrace that includes functions in auditors. What they do
not want to see is: "During startup program terminated with ..." error and no
active process. 

likewise when you list a function:

(gdb) list function

you need to be able to disambiguate which function with that name you want to
list. Do you want the one in the app or the one in a particular auditor. Unlike
breakpoints where you could conceivably set points everywhere, defaulting to
the first found could be a problem that makes functions that have the same name
as one in the app could render the function inaccessible. 

(gdb) list {1}function

could allow a user to list the one that exists in the auditor vs. the one in
the app.

When you specify a source location the file location needs to be qualified with
the namespace as well otherwise you may refer to a line of code in the wrong
translation unit. For example does:

(gdb) break filename.c:237 

refer to the filename.c in the app or one in an auditor. A very likely case is
that an auditor is built against one version of libstdc++ while the app is
linked against another. Since these two versions of libstdc++ come from the
same basic source just different generations of that source the chance of
duplicate filenames is very likely however the line number for a particular
block of code could be entirely different due to code changes in libstdc++.
Therefore, handling duplicate filenames is not something that is unlikely. Once
again using the namespace qualifier helps disambiguate the situation.

(gdb) break {1}filename.c:237

A heuristic for symbol searching that was suggested is to have gdb first look
in the namespace for the current frame. If the symbol is not found, then look
in the other namespaces.

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

[Bug gdb/29181] Support dlmopen and LD_AUDIT private namespaces

[ppluzhnikov at google dot com]

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

Paul Pluzhnikov <ppluzhnikov at google dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ppluzhnikov at google dot com

--- Comment #1 from Paul Pluzhnikov <ppluzhnikov at google dot com> ---
This is probably a duplicate of bug#11839

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

[Bug gdb/29181] Support dlmopen and LD_AUDIT private namespaces

[woodard at redhat dot com]

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

--- Comment #2 from Ben Woodard <woodard at redhat dot com> ---
(In reply to Paul Pluzhnikov from comment #1)
> This is probably a duplicate of bug#11839

There are patches floating around by Markus Metzger which seem to address
bug#11839 better. The last time that I checked in on it he was at V5 of the
patchset and they could be found in users/mmetzger/dlmopen.

This bug is more related to usability problems that show up after Markus's
patches have been applied and gdb is properly searching all the loaded
linkmaps. So this is more gdb UI related.

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