public inbox for gdb-prs@sourceware.org help / color / mirror / Atom feed
From: "woodard at redhat dot com" <sourceware-bugzilla@sourceware.org> 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 [thread overview] Message-ID: <bug-29181-4717@http.sourceware.org/bugzilla/> (raw) 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.
next reply other threads:[~2022-05-25 20:25 UTC|newest] Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-05-25 20:25 woodard at redhat dot com [this message] 2022-09-09 21:15 ` [Bug gdb/29181] " ppluzhnikov at google dot com 2022-09-09 21:44 ` woodard at redhat dot com
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-29181-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: linkBe 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).