From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id D6E68383067B; Wed, 25 May 2022 20:25:28 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org D6E68383067B From: "woodard at redhat dot com" To: gdb-prs@sourceware.org Subject: [Bug gdb/29181] New: Support dlmopen and LD_AUDIT private namespaces Date: Wed, 25 May 2022 20:25:28 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gdb X-Bugzilla-Component: gdb X-Bugzilla-Version: HEAD X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: woodard at redhat dot com 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 X-BeenThere: gdb-prs@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-prs mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2022 20:25:29 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D29181 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 her= e: 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 partic= ular library that was loaded by the dynamic linker into a private namespace vs o= ne 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:=20 (gdb) info shared From To Syms Read Shared Object Library 0x00007ffff7fc8090 0x00007ffff7feea45 Yes=20=20=20=20=20=20=20=20 /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=20=20=20=20=20=20=20=20 /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 Obje= ct 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 requ= est is that the same syntax used by GDB to print a symbol should be accepted wh= en 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 confu= sing 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=E2=80=A6) + 7 or (gdb) print 3::my_function_in_namespace2(args=E2=80=A6) + 7 When listing breakpoints the namespace in which the breakpoint exists shoul= d be listed when enumerating the breakpoints.=20 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 te= ams that work on apps are different. The teams that work on tools are intereste= d 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.=20 Similarly backtraces need to denote when a particular symbol exists in priv= ate namespace. Turning something like: (gdb) bt #0 doPrint (output=3D...) at auditlib.cpp:30 #1 0x00007ffff7fb4cf0 in la_activity (cookie=3D,=20 flag=3D) at /usr/include/c++/11/bits/char_traits.h:3= 57 #2 0x00007ffff7fdf415 in _dl_audit_activity_map (l=3Dl@entry=3D0x7ffff7f= fe2a0,=20 action=3Daction@entry=3D1) at dl-audit.c:33 #3 0x00007ffff7fe6c98 in dl_main (phdr=3D,=20 phnum=3D, user_entry=3D, auxv=3D) at rtld.c:1832 #4 0x00007ffff7fe328f in _dl_sysdep_start ( start_argptr=3Dstart_argptr@entry=3D0x7fffffffdbe0,=20 dl_main=3Ddl_main@entry=3D0x7ffff7fe52a0 ) at ../elf/dl-sysdep.c:256 #5 0x00007ffff7fe503e in _dl_start_final (arg=3D0x7fffffffdbe0) at rtld.= c:507 #6 _dl_start (arg=3D0x7fffffffdbe0) at rtld.c:596 #7 0x00007ffff7fe3e38 in _start () from /lib64/ld-linux-x86-64.so.2 into: (gdb) bt #0 {1}doPrint (output=3D...) at auditlib.cpp:30 #1 0x00007ffff7fb4cf0 in {1}la_activity (cookie=3D,=20 flag=3D) at /usr/include/c++/11/bits/char_traits.h:3= 57 #2 0x00007ffff7fdf415 in _dl_audit_activity_map (l=3Dl@entry=3D0x7ffff7f= fe2a0,=20 action=3Daction@entry=3D1) at dl-audit.c:33 #3 0x00007ffff7fe6c98 in dl_main (phdr=3D,=20 phnum=3D, user_entry=3D, auxv=3D) at rtld.c:1832 #4 0x00007ffff7fe328f in _dl_sysdep_start ( start_argptr=3Dstart_argptr@entry=3D0x7fffffffdbe0,=20 dl_main=3Ddl_main@entry=3D0x7ffff7fe52a0 ) at ../elf/dl-sysdep.c:256 #5 0x00007ffff7fe503e in _dl_start_final (arg=3D0x7fffffffdbe0) at rtld.= c:507 #6 _dl_start (arg=3D0x7fffffffdbe0) 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 lib= rary 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.=20 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. Un= like 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.=20 (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=20 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 lo= ok in the namespace for the current frame. If the symbol is not found, then lo= ok in the other namespaces. --=20 You are receiving this mail because: You are on the CC list for the bug.=