From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-f53.google.com (mail-wr1-f53.google.com [209.85.221.53]) by sourceware.org (Postfix) with ESMTPS id 1D01D3858415 for ; Wed, 9 Mar 2022 14:15:19 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 1D01D3858415 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=palves.net Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-wr1-f53.google.com with SMTP id j17so3347287wrc.0 for ; Wed, 09 Mar 2022 06:15:19 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=dHcfpu5xsrPuEuSFPkvJK9wjqbvsWnl/3eWSRPOriUk=; b=ipIL5/qYfrg1cx46uhiBYFUshfAGlgCy1yg2lExw1yGpAYzUZOh7uC/Uo6G17xoAPs Aq1zBZbGKw9sAiGUNY2Gd5+WeqqYRg21T8unaJluBjJSbovTrUr6r0i2hPp+qTjNjRhO mwL8raAQhRIT3x/aTrgowPgG//cHDXt/oxKX/0GyVJBBKhhWfKxLp/pJLG3jZ9lXDptM fitcl+HL/dJvShigHuG5dak2TcXcMEb6Z9xfZvDojbnbnBYuvUmSZA+gdMaS4tSFPLQq GjGgFj35g7xj3d3tFKPW1u2jHxPuiIuTCEtrDyqxkkidFVZa7CbkRvj5AJ92KJ4CV6TH ZJtQ== X-Gm-Message-State: AOAM532G2fXnCzVuGiDFrBK0NdjKqh1kUI6kcSI1vD7QAOGDripXFmjE NwrwS+99ULbhnkzROvuBSwE= X-Google-Smtp-Source: ABdhPJy+valXu90zQgkNYV4P0WMXBHmIQmEQ2N2K484U3dB2YyZ+evL2G8qOa0kukQZ09v+0STxWQQ== X-Received: by 2002:adf:fbc4:0:b0:1e7:2060:d65 with SMTP id d4-20020adffbc4000000b001e720600d65mr15815063wrs.583.1646835317906; Wed, 09 Mar 2022 06:15:17 -0800 (PST) Received: from ?IPV6:2001:8a0:f924:2600:209d:85e2:409e:8726? ([2001:8a0:f924:2600:209d:85e2:409e:8726]) by smtp.gmail.com with ESMTPSA id q125-20020a1c4383000000b003899720641dsm5236732wma.30.2022.03.09.06.15.16 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 09 Mar 2022 06:15:16 -0800 (PST) Message-ID: <9e7f445c-67cc-ebc1-566b-529c6dc8924b@palves.net> Date: Wed, 9 Mar 2022 14:15:15 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.6.1 Subject: Re: [PATCH v4] gdb, gdbserver: support dlmopen() Content-Language: en-US To: "Metzger, Markus T" Cc: "gdb-patches@sourceware.org" References: <20211117142812.3685162-1-markus.t.metzger@intel.com> From: Pedro Alves In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3.9 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) 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: Wed, 09 Mar 2022 14:15:20 -0000 On 2022-03-09 12:24, Metzger, Markus T wrote: > Hello Pedro, > >> Should the commit have a Co-Authored-By: tag for H.J.? > > Definitely. I didn't know we were using such tags. > > >> I'm wondering whether ideally symbol lookup would be updated to handle >> different namespaces. I'm thinking of for example >> svr4_iterate_over_objfiles_in_search_order. > > Do you mean that we should restrict the search to the namespace of the > current_objfile argument? And use, say, the default namespace if that is nullptr? Something like that. I mean, doesn't the dynamic loader restrict resolving symbols to the same namespace (and then the global namespace, I guess)? Not sure about completely restricting to the namespace is what users would want, but at least I'd think we should search symbols in the current namespace first before searching the global namespace and then other namespaces (*). The idea being that evaluating an expression in GDB should yield the same result the same expression would yield if coded in the program. (*) Similar 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 point, I haven't thought about actual use cases, but I think it's worth it to ponder about it. Pedro Alves > > >> Can you describe what xml changes were necessary? Do we need to update >> the manual where the xml/packet are described? > > This patch doesn't change the XML so everything ends up in a flat list and GDB > doesn't really know about namespaces. This prevents incremental updates > and would also prevent things like the above. > > I had planned to leave support for that for backwards compatibility and update > the XML to pass namespaces for future versions. See also > https://sourceware.org/pipermail/gdb-patches/2022-February/186135.html. > > If we need GDB to know about namespaces, however, this wouldn't work and > we'd instead need to conditionalize namespace support based on gdbserver > features. >