From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS3215 2.6.0.0/16 X-Spam-Status: No, score=-4.2 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [IPv6:2620:52:3:1:0:246e:9693:128c]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 3B1191F8C6 for ; Wed, 28 Jul 2021 20:05:41 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 15B8A383D008 for ; Wed, 28 Jul 2021 20:05:40 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 15B8A383D008 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1627502740; bh=Pt5TkwkdY9ERhe/SxJP2BZW+fr37JEf2pYg3X30zw0Y=; h=References:In-Reply-To:Date:Subject:To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=uwgp6nAPGB6+1XvPysnChubP7ht/YUUX1tz2J699DAA/A+Nhk+c8D5I+Ayl7c26eV RoVSldmzmzPwq/RsvyblYX5NZ2Z/i2FkZyExz4rzKHU8WZdq8S9v1vf309j38DLTiG 0ManIDzhh0LuZiOqgZwZ9XkdIUwvRWoFOh5fiZhg= Received: from mail-pl1-x635.google.com (mail-pl1-x635.google.com [IPv6:2607:f8b0:4864:20::635]) by sourceware.org (Postfix) with ESMTPS id F20AD385C405 for ; Wed, 28 Jul 2021 20:05:18 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org F20AD385C405 Received: by mail-pl1-x635.google.com with SMTP id f13so4100168plj.2 for ; Wed, 28 Jul 2021 13:05:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Pt5TkwkdY9ERhe/SxJP2BZW+fr37JEf2pYg3X30zw0Y=; b=H0JH4k5iA8ZY/2VOtqJMLIQvq+XzRfeTWisr8d1OfCzCF43BVbEze1f5APXbm/dKWC jNZpMtLbczwnGHHCYJDa59i4wVUpe4AXOD4n3pP1s/2YGshGmpMb7JmeYw3HcpInCrFI 5ZEubqN/0G/frrLFOPcorlfV6MEtLrWWKWQANQ+CM2SGjor7Ki3RZyqOAP9EugasimFl 68vOXs9ieXV73QZTbC0LuzsDDyC9m7wktAn+25to0jqT6UP9W7XumiTt7pONVFFhYCXM aCrTGa4E2vgxRpqkpW+SG6WbtBi6B9TxXl1F6pWhkUbxUG4nesmMPvUxaMJbrziHrfPb JqCw== X-Gm-Message-State: AOAM530eO2tSmIVszb79LOrM/TAa3bqtx5+uVAq1Zn9gQI7iHxk3OqWV PRuhuvh05AXawA5j63DTSjOiyuh/d4JaboyBOVw= X-Google-Smtp-Source: ABdhPJyzyGO5cv5c4aEs3rvg8kTOaJmhLPBBnkFsIpwrjJ/2thJCyUFGoVeDhSYBJ3ubvT18CPXDg7jDFAJcbqNqwtA= X-Received: by 2002:a17:90a:c902:: with SMTP id v2mr11161594pjt.136.1627502718066; Wed, 28 Jul 2021 13:05:18 -0700 (PDT) MIME-Version: 1.0 References: <7e2fb426-cf03-a8e7-6524-a5f81fcf5b9e@redhat.com> <87ftagyhra.fsf@mid.deneb.enyo.de> <8a15bd93-e4cc-a3bc-f902-5b3e701ec4e3@redhat.com> <87y2o61chx.fsf@oldenburg2.str.redhat.com> <20210727173958.GB1633923@zorba> <20210728154408.GF1633923@zorba> <20210728190211.GJ1633923@zorba> In-Reply-To: <20210728190211.GJ1633923@zorba> Date: Wed, 28 Jul 2021 13:04:42 -0700 Message-ID: Subject: Re: [RFC PATCH 3/3] add r_debug multiple namespaces support To: Daniel Walker Content-Type: text/plain; charset="UTF-8" X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: "H.J. Lu via Libc-alpha" Reply-To: "H.J. Lu" Cc: Florian Weimer , Carlos O'Donell via Libc-alpha , Pedro Alves , Conan C Huang , "Metzger, Markus T" , Florian Weimer , Jeremy Stenglein , xe-linux-external@cisco.com Errors-To: libc-alpha-bounces+e=80x24.org@sourceware.org Sender: "Libc-alpha" On Wed, Jul 28, 2021 at 12:02 PM Daniel Walker wrote: > > On Wed, Jul 28, 2021 at 10:14:41AM -0700, H.J. Lu wrote: > > On Wed, Jul 28, 2021 at 8:44 AM Daniel Walker wrote: > > > > > > On Wed, Jul 28, 2021 at 08:15:10AM -0700, H.J. Lu wrote: > > > > On Tue, Jul 27, 2021 at 11:14 AM H.J. Lu wrote: > > > > > > > > > > On Tue, Jul 27, 2021 at 10:40 AM Daniel Walker wrote: > > > > > > > > > > > > On Fri, Jul 23, 2021 at 04:38:33PM -0700, H.J. Lu wrote: > > > > > > > On Mon, Jun 29, 2020 at 2:49 AM Florian Weimer via Libc-alpha > > > > > > > wrote: > > > > > > > > > > > > > > > > * Carlos O'Donell via Libc-alpha: > > > > > > > > > > > > > > > > >>> I'm not sure it would work to version _r_debug, since the debugger > > > > > > > > >>> is using DT_DEBUG and we only get to put one value in that > > > > > > > > >>> .dynamic entry. > > > > > > > > >> > > > > > > > > >> The symbol version is needed to avoid problems due to copy relocations > > > > > > > > >> if the symbol is referenced directly from the main program. Without > > > > > > > > >> that, the object could be truncated. It's not a debugger > > > > > > > > >> compatibility feature. > > > > > > > > > > > > > > > > > > Correct, but this violates *how* you're supposed to use _r_debug. > > > > > > > > > > > > > > > > If it is possible to link against it, we need to add the new symbol > > > > > > > > version, in my opinion. > > > > > > > > > > > > > > > > > In the dynamic case it is different. The symbol should be looked up > > > > > > > > > via DT_DEBUG only which always points to the library-local address > > > > > > > > > of the data object (and the most recent version). In effect this > > > > > > > > > bypasses the COPY relocation? > > > > > > > > > > > > > > > > How is this supposed to work if the dynamic linker does contain > > > > > > > > DT_DEBUG? > > > > > > > > > > > > > > > > I only observe DT_DEBUG in PIE binaries, but since the dynamic loader is > > > > > > > > mapped at a random address even for ET_EXEC main programs, there must be > > > > > > > > some other mechanism to locate it. > > > > > > > > > > > > > > > > Thanks, > > > > > > > > Florian > > > > > > > > > > > > > > > > > > > > > > I opened: > > > > > > > > > > > > > > https://gitlab.com/x86-psABIs/Linux-ABI/-/issues/2 > > > > > > > > > > > > > > with a proposal to extend struct r_debug for libraries loaded with > > > > > > > dlmopen, I'd like to resolve it for the next releases of glibc, binutils > > > > > > > and GDB. > > > > > > > > > > > > > > > > > > I have an updated set of changes which add a new dynamic entry > > > > > > DT_DEBUG_DLMOPEN, which was recommended by Carlos. We're still testing the > > > > > > implementation. I'm open to support different implementations. > > > > > > > > Please send an email to gABI group: > > > > > > > > https://groups.google.com/g/generic-abi > > > > > > > > to add a new DT_XXX. If it is impractical to add a new DT_XXX to gABI, > > > > I propose DT_GNU_DEBUG: > > > > > > > > https://gitlab.com/x86-psABIs/Linux-ABI/-/issues/2 > > > > > > > > to cover dlmopen and beyond. > > > > > > > > > > > > > The last time this was discussed I thought this was the gABI group. Someone had > > > said gABI was getting taken over by glibc. > > > > There are 2 gABI groups: > > > > 1. OS independent gABI: > > > > https://groups.google.com/g/generic-abi > > > > 2. Linux/GNU specific extensions to gABI: > > > > https://sourceware.org/mailman/listinfo/gnu-gabi > > > > We can try #1 first. > > Do you want to drive this, or should I ? It looks like you know the people > involved better than I do. > https://groups.google.com/g/generic-abi/c/1ngxmSwrafc -- H.J.