From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id wJ3+DSBilmKsiwkAWB0awg (envelope-from ) for ; Tue, 31 May 2022 14:44:48 -0400 Received: by simark.ca (Postfix, from userid 112) id 2E3E51E221; Tue, 31 May 2022 14:44:48 -0400 (EDT) Authentication-Results: simark.ca; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.a=rsa-sha256 header.s=default header.b=eV+f4UkC; dkim-atps=neutral X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-3.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 5A4251E00D for ; Tue, 31 May 2022 14:44:47 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 5AABD395B411 for ; Tue, 31 May 2022 18:44:45 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 5AABD395B411 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1654022685; bh=icg0dWIj+nsZ+02FnEg4E+Z3K/ideA3HUPBY7yDIwYU=; h=Subject:In-Reply-To:Date:References:To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=eV+f4UkCkc5jiS8i04tcx63HUcWiB4suTiaB8iY7f2o6qjsyfpoZ1xLsJDApQEBFb vCcTBoJdE1x6FPFEwzJxNlurtQSajcftUSk3uVhtt5gHeN4Euits90gEGYvf79P3qf BkR6a+rHSC5nwdQEZTTpfSHzY9D4Kr+p3sAp84Bk= Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id B424B395B066 for ; Tue, 31 May 2022 18:44:24 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org B424B395B066 Received: from mail-oa1-f71.google.com (mail-oa1-f71.google.com [209.85.160.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-20-O3cXDuaAPhGRTzfD5zPsmw-1; Tue, 31 May 2022 14:44:23 -0400 X-MC-Unique: O3cXDuaAPhGRTzfD5zPsmw-1 Received: by mail-oa1-f71.google.com with SMTP id 586e51a60fabf-f32f6522c6so4904112fac.18 for ; Tue, 31 May 2022 11:44:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=qoWlTxjb1Lb9IC4YSlG64ZJDW7SiYvo7J5tZ3wgC4iA=; b=JPJBxwroxfXPRKBJEL9TjL6jgRwgEkeCfRcQVXpfVrlaP8TrfwPt5cr5S0oPLtBFVZ RbeB+wLK2fr0rKgmA6zHyGfX6DJ53NqbT8dnjb8qunT4NHlZAe5XpvnaPNAWP2gZfVqw EiyNa2Yq1BXwWFBNmjgERR45d9Tpdmn8gYMj7nRDJO8MtpQnjKV1BOKRgDJ1omkZe2UW jy++NnoBCUhMdofg4fzTuOUN2hU4lmk57uQcFUg9NT+0i50lZe6WhkWxbUOd8BiJOrrN ZarUDc6kHIb4/znnANzaKdPPjrBfx+3BUqgdHnHaZp7F3nAHzTQp0piZhbN9Qa26Ve8H CdRg== X-Gm-Message-State: AOAM530vZorz8mCvYZnIgHMDHV7a5ICC+lCuu+oOT7WXkWjUrPZ2DKnE NwEsThq71nvbC4PLpmjtTJezfEruGCVIGl5zrdTpKjsTM7qUWWgCMbE7etLnrgbHKig24LX7Qp9 ZkOfouOzwgY2cjdyP57SugA== X-Received: by 2002:a05:6808:1805:b0:32b:17e3:c7b with SMTP id bh5-20020a056808180500b0032b17e30c7bmr13031760oib.37.1654022662449; Tue, 31 May 2022 11:44:22 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyyVvgIT90/KCHQjMXKnP6w2scZ5EFfh4TuW8YhsfumsjlAYIeHa8mRHyO14MhmIRVu9B44PA== X-Received: by 2002:a05:6808:1805:b0:32b:17e3:c7b with SMTP id bh5-20020a056808180500b0032b17e30c7bmr13031743oib.37.1654022661950; Tue, 31 May 2022 11:44:21 -0700 (PDT) Received: from smtpclient.apple ([47.208.199.57]) by smtp.gmail.com with ESMTPSA id g18-20020a9d5f92000000b006060322127esm6494258oti.78.2022.05.31.11.44.20 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 31 May 2022 11:44:21 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.100.31\)) Subject: Re: [PATCH v4] gdb, gdbserver: support dlmopen() In-Reply-To: Date: Tue, 31 May 2022 11:44:17 -0700 Message-Id: <3C350494-B74E-4F5F-A649-FD2DCD81B2BE@redhat.com> References: <20211117142812.3685162-1-markus.t.metzger@intel.com> <20220525101204.087efe18@f35-zws-1> To: "Metzger, Markus T" 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-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: , From: Ben Woodard via Gdb-patches Reply-To: Ben Woodard Cc: "gdb-patches@sourceware.org" Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" > On May 31, 2022, at 2:29 AM, Metzger, Markus T wrote: >=20 > Thanks Kevin and Ben, for your positive feedback on the usefulness of thi= s. >=20 > The patch has grown into a small series when I added gdbserver support > and changed several occurrences of direct objfiles traversal with calls t= o > gdbarch_iterate_over_objfiles_in_search_order() to take namespaces into > account. >=20 > The latest version can be found in users/mmetzger/dlmopen. I'll also sen= d > it as v5 with a few opens left. >=20 >> While I'm convinced that other work will be needed to improve GDB's UI >> to both display linker namespaces (e.g. in the "info shared" command) >> and accept namespace qualifiers when specifying a symbol (e.g. with a >> breakpoint command), I think that this current patch is useful as >> is. I.e., I'd like to see it (or a modest update) go in as soon as >> possible. >=20 > Indeed, there are a few known issues and many direct objfiles traversals > in GDB that all assume that there can be at most one global symbol > of the same name. Fixing all of them will be a fair amount of work. >=20 > Ben Woodard: >> How do I specify the filename.c TU which is part of the libstdc++.so whi= ch is >> linked into one of the audit libraries rather than the one that is linke= d into the >> app. Path to the filename isn't sufficient because they could have both = been built >> in the same directory structure from different sources. That is why I be= lieve that >> we need some way to know which shared objects are in which namespace and >> some way to specify which linkage namespace to search. >>=20 >> Since the linkage namespaces are on a linked list in glibc, I thought re= ferring 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 that I = am hung >> up on. If someone has a better idea, great. >=20 > I currently keep namespaces hidden and local to SVr4. The rest of GDB do= esn't > know about them. >=20 > The official namespace id that dlinfo(RTLD_DI_LMID) provides is available= for > dynamic linker notifications but not during the (initial) load map scan -= or I > haven't found it. I use the address of the r_debug(_ext) object as ident= ifier. >=20 To me this sounds like a weakness in the r_debug interface that glibc provi= des, shall we bring this up to with the glibc folk? Sure they would have to bump it up to version 3 but, I do not think any Uni= x has been here before and we are probably running into issues that no one = has had to consider before. I think that you could probably explain the issue on glibc-alpha better tha= n I can but I can take that on if it would help advance the topic. > We could simply number them, as Ben suggests, using the ordinal in the > r_debug chain. This may be confusing to users who are aware of the actua= l > namespace id, though. >=20 I think using the namespace ID is a better idea than my ordinal numbering s= ystem. Mostly, I just felt GDB some sort of handle to disambiguate symbols = that exist in different namespaces. > To make GDB aware of namespaces, we'd probably want to partition > solibs and objfiles by namespace. This will be a big patch when we chang= e > program_space::objfiles() to take a namespace id argument and update all > users. >=20 > Ideally, I think we'd want objfiles to be shared so we only read the debu= g > info once per unique instance and relocate it lazily but GDB is currently= not > doing that and it doesn't sound entirely trivial. Yeah with DWARF being what it is, you really do not want to blow up the mem= ory utilization unnecessarily. However, I think increased memory utilizatio= n by debuggers is preferable to not being able to debug audiors effectively= . I am not intimately aware of GDB=E2=80=99s internals but I can imagine a= lot of data structures having to change to go from a symbol pointing to on= e address in one loaded object to a symbol referring to a set of objects an= d addresses. That doesn=E2=80=99t sound trivial. -ben >=20 > regards, > markus. > Intel Deutschland GmbH > Registered Address: Am Campeon 10, 85579 Neubiberg, Germany > Tel: +49 89 99 8853-0, www.intel.de > Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva= =20 > Chairperson of the Supervisory Board: Nicole Lau > Registered Office: Munich > Commercial Register: Amtsgericht Muenchen HRB 186928 >=20