From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 6AF703948830 for ; Tue, 24 May 2022 18:40:09 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 6AF703948830 Received: from mail-oo1-f69.google.com (mail-oo1-f69.google.com [209.85.161.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-563-9h3GyazIM_iJ97Nr9MCNLA-1; Tue, 24 May 2022 14:40:07 -0400 X-MC-Unique: 9h3GyazIM_iJ97Nr9MCNLA-1 Received: by mail-oo1-f69.google.com with SMTP id c1-20020a4aa4c1000000b0035e95332a48so9024533oom.7 for ; Tue, 24 May 2022 11:40:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:cc:to; bh=3XqV4Yk9xwTyLVQAvzc+u7T94lmjle0gGDLqHbU9omg=; b=isgtH90vJj0unQac/vLY2XcGW7mbfqhpFLJAJpLwF5zrsbT/MFHxVtQrtW3qNRii4+ c4BI3s6iyEu9Abd5XpS62VgQLsyk0hpLAWdoDlduEWPFLx9RXrxBxddzTa50dVvFaqN7 l4CGr3F8vPgs4SF8pxYU6v/bKBx0NcS0UaTyeeIaTPWSoT1GppPhRhVyVZ4k8dmLNw97 +02hcBmK5NRP6W3QfVxyZ+br5CrPkdvF1UI0sEcAj8BbhmbnD2gbt0f6dXHpJiLxhbrD F8raeWKjUiK8lpRqWGeCNQqVkyCyH2iVecBYdKlsLiT6rnoJjNV1VbUDGlFOqkWwVszb 1ifw== X-Gm-Message-State: AOAM533oFBdczxcZNHey4j7q+sry/xN3ymb9Sk0kC32hir4RSFFaO1iO A4popTAy0g5OH+HsfshFGMUEqUVWbROgWObBB+4HJ5Q83KZXSukVyiVitrssMwKi7ah2oSvyQHB 1wuGNaQfQHdAv3QEirF5/oqddZJHR3Z3Jis1XltBaehKZFjlqiUnEZhB4aEgn8iOJ60OQnO6a X-Received: by 2002:a05:6808:1704:b0:2f9:bb17:21f6 with SMTP id bc4-20020a056808170400b002f9bb1721f6mr3011309oib.23.1653417606637; Tue, 24 May 2022 11:40:06 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwThU1CDCaGCsei3dEJyp9s8a4WpSleLY87sk+/+LpQbokscfIxw1W1KCBvOMdUZJ1I8GDAwQ== X-Received: by 2002:a05:6808:1704:b0:2f9:bb17:21f6 with SMTP id bc4-20020a056808170400b002f9bb1721f6mr3011288oib.23.1653417606089; Tue, 24 May 2022 11:40:06 -0700 (PDT) Received: from smtpclient.apple ([47.208.199.57]) by smtp.gmail.com with ESMTPSA id i127-20020aca3b85000000b00325cda1ffa5sm5516765oia.36.2022.05.24.11.40.05 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 24 May 2022 11:40:05 -0700 (PDT) From: Ben Woodard Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.100.31\)) Subject: [PATCH v4] gdb, gdbserver: support dlmopen() Message-Id: Date: Tue, 24 May 2022 11:40:03 -0700 Cc: Kevin Buettner , Ben Woodard To: gdb-patches@sourceware.org X-Mailer: Apple Mail (2.3696.100.31) X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-6.1 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2022 18:40:11 -0000 Sorry for the late feedback. I was not aware of Markus=E2=80=99s patch unti= l yesterday when Kevin pointed it out to me. I=E2=80=99ve just started play= ing with a test build that Kevin gave me.=20 > On 2022-03-09 12:24, Metzger, Markus T wrote: > Hello Pedro,=20 > >=20 > >> Should the commit have a Co-Authored-By: tag for H.J.?=20 > >=20 > > Definitely. I didn't know we were using such tags.=20 > >=20 > >=20 > >> I'm wondering whether ideally symbol lookup would be updated to handle= =20 > >> different namespaces. I'm thinking of for example=20 > >> svr4_iterate_over_objfiles_in_search_order.=20 > >=20 > > Do you mean that we should restrict the search to the namespace of the= =20 > > current_objfile argument? And use, say, the default namespace if that i= s nullptr?=20 > Something like that. I mean, doesn't the dynamic loader restrict resolvin= g symbols to the same namespace (and then the global namespace, I guess)? N= ot sure about completely restricting to the namespace is what users would w= ant, but at least I'd think we should search symbols in the current namespa= ce first before searching the global namespace and then other namespaces (*= ). The idea being that evaluating an expression in GDB should yield the sam= e result the same expression would yield if coded in the program. (*) Simil= ar to how we search symbols in scope, and can still print static globals of= other files even if they're not in scope. It's just a question at this poi= nt, I haven't thought about actual use cases, but I think it's worth it to = ponder about it.=20 I actually have thought about this a lot and have customers which have aske= d me for this feature.=20 The real use case is not dlmopen(); I=E2=80=99m not really sure I=E2=80=99v= e seen anyone actually use dlmopen(). The real use case is LD_AUDIT and DT_= AUDIT / DT_DEPAUDIT. The dynamic linker is antiquated and doesn=E2=80=99t m= eet our needs but it evidently cannot be changed. LD_AUDIT allows us to get= in there and change the dynamic linker=E2=80=99s behavior so that it can b= e made to meet our needs.=20 Tool developer need to debug their code the same way that app developers do= . Without support like Markus=E2=80=99s patch this is EXTREMELY difficult. = When we wrote Spindle https://computing.llnl.gov/projects/spindle getting i= t working was PAINFUL. We had to write tools to write tools. The thing is t= ool developers and app developers are different. Thinking of it as one big = namespace is OK but it is unwieldy for tool developers. One big thing that = we need is the ability to disambiguate symbols based upon which namespace t= hey are found in. App developers have quite a few different compilers that they use. The tool= developers have had extra work maintaining their tools because they had to= make them work with every compiler and libstdc++ combination in use becaus= e they were using the same libstdc++ and boost libs that the apps used. Thi= s introduced a lot of extra support cost for the tool developers. What they= are trying to get to is a place where they can make one version of the too= l using their preferred version lof libstdc++ and boost (and whatever other= libraries) and have it insulated from the application. Then they give the = application authors some magic invocation for their link line which sets up= the DT_AUDIT and DT_DEPAUDIT voila=E2=80=99 their tool is =E2=80=9Calways = on=E2=80=9D. The upshot of this is that there will likely be two versions o= f libstdc++ and likely other libraries loaded into the process=E2=80=99s ad= dress space. With Markus=E2=80=99s patch we can now see all the libraries: (gdb) info shared From To Syms Read Shared Object Librar= y 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 Great! The problem is we don=E2=80=99t know which ones are in which namespa= ce. It would be great if we had something like: (gdb) info shared From To Syms Read NS=09Shared Object L= ibrary 0x00007ffff7fc8090 0x00007ffff7feea45 Yes 1=09/lib64/ld-linux-= x86-64.so.2 0x00007ffff7fb12a0 0x00007ffff7fb9022 Yes 1=09./auditlib.so 0x00007ffff7df73f0 0x00007ffff7eff532 Yes 1=09/lib64/libstdc++= .so.6 0x00007ffff7c873b0 0x00007ffff7cf8b58 Yes 0=09/lib64/libm.so.6 0x00007ffff7c5a670 0x00007ffff7c70c05 Yes 0=09/lib64/libgcc_s.= so.1 0x00007ffff7a82740 0x00007ffff7bf371d Yes 1=09/lib64/libc.so.6 0x00007ffff7fc8090 0x00007ffff7feea45 Yes 0=09/lib64/ld-linux-= x86-64.so.2 0x00007ffff777d740 0x00007ffff78ee71d Yes 0=09/lib64/libc.so.6 Then when we want to set a breakpoint on a symbol or something we can quali= fy it with the namespace something like: (gdb) b 1::printf The problem with lazily searching all namespaces and setting breakpoints at= all of the functions is most evident with C++ inline functions expanded fr= om header files. There can be thousands of functions in the app which are n= ot interesting to a tool developer. Tool developers tend to want to focus o= n developing the tool while app developers focus on their app. The tool dev= eloper may need to use the app as a reproducer while debugging their tool. Similar problems seem to abound in other places where the lack of a way to = disambiguate namespaces can be a problem: When I say: (gdb) list How do I get it to show me the version of the function which is in the firs= t private namespace vs. the version which is in the application? or when I do something like: (gdb) break filename.c:231 How do I specify the filename.c TU which is part of the libstdc++.so which = is linked into one of the audit libraries rather than the one that is linke= d into the app. Path to the filename isn=E2=80=99t sufficient because they = could have both been built in the same directory structure from different s= ources. That is why I believe that we need some way to know which shared ob= jects are in which namespace and some way to specify which linkage namespac= e to search. Since the linkage namespaces are on a linked list in glibc, I thought refer= ring to the default namespace as 0 and counting the depth and then reusing = the C++ namespace qualifier might be a good idea but it is not something th= at I am hung up on. If someone has a better idea, great. Anyway, that is my first pass at feedback. Once I get feedback from other d= evelopers that I work with and have more time to play with the build that K= evin gave me, I=E2=80=99ll have more for you guys. -ben > Pedro Alves