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-Status: No, score=-4.1 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI, SPF_HELO_PASS,SPF_PASS,URIBL_BLOCKED shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 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 (4096 bits) server-digest SHA256) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id C3DF81F5AE for ; Sun, 28 Jun 2020 12:34:52 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 540E6388E825; Sun, 28 Jun 2020 12:34:51 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 540E6388E825 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1593347691; bh=lxnrYYhV2ZUq/drNTt9ai36u/0uK/W9wX35jPoQfpHk=; h=Subject:To:References:Date:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=KlqMRnchVHQ6xD0f/esc6fckSyaPQsBFT5apJFgpSDWucXmArZN96g7bGRnDzYXw1 XSHfbR8x6YMMBXIT7zeo83BsLrg+9z9MQAw/q28PmFMnG1/7m/hdnwntbOLiSD/HD7 GdkQTEs4G13JKpy4cvgqKXhCsZ1whXwG72YRep5U= Received: from us-smtp-delivery-1.mimecast.com (us-smtp-2.mimecast.com [205.139.110.61]) by sourceware.org (Postfix) with ESMTP id F0D73388E81F for ; Sun, 28 Jun 2020 12:34:48 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org F0D73388E81F Received: from mail-qv1-f71.google.com (mail-qv1-f71.google.com [209.85.219.71]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-336-18uaxQw_M8OJs-TVxP6LJg-1; Sun, 28 Jun 2020 08:34:46 -0400 X-MC-Unique: 18uaxQw_M8OJs-TVxP6LJg-1 Received: by mail-qv1-f71.google.com with SMTP id y36so9803923qvf.21 for ; Sun, 28 Jun 2020 05:34:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=lxnrYYhV2ZUq/drNTt9ai36u/0uK/W9wX35jPoQfpHk=; b=U9f9mEy6IEBaGrFVDK6O8U7MMSZl+08tNAYMyJTPt+ypPEqQG1KW74pEJ67gZR/UnT bD2pcAajkB91uyX+VawjMipHLY5Ja1AyiiO9odZoKLDK9vRD89I96tLqTLk08hUEcahQ RFh3Hz+GSdiULqgNO4GRtTpIqDa+tzdNKqSSsKlXuRnlahwmZ7/0zKLKqAE+0e/HAltn OOs6xetZPMK5WDYllUaJYMutll/qtBJFWs7TXmuVEBZv5i1p8Si3CCrlbtSebn5s6nQP ycy/gNkN7InhDGsW8y8Ostxhxk/URx0dTcoR+dvSW/RnYeITMnCbAvMyVGeVpUHYFjc5 oZqg== X-Gm-Message-State: AOAM5331lf8jnfpi0n7Uyjsl9zDSF6IVqjeA9Mydfbf365+vMgaWhCKG 4LUEairXI8PxHAbvMZh6J0NfV5Xd1hQP2r7/vet1OrKno+rQ0C6PNnuP5ZFcPya7N5jz+WpWDab wKvL8/SHAWLFJ42QZgMfd X-Received: by 2002:a37:6388:: with SMTP id x130mr745294qkb.220.1593347685773; Sun, 28 Jun 2020 05:34:45 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw9O26UYVW1e2Cn9WWiyT6sEi3r6GZ7T4+8UKIcsCrzlkMLR/Broy40eg6zMH7Pvi1YEQvtbg== X-Received: by 2002:a37:6388:: with SMTP id x130mr745282qkb.220.1593347685554; Sun, 28 Jun 2020 05:34:45 -0700 (PDT) Received: from [192.168.1.4] (198-84-170-103.cpe.teksavvy.com. [198.84.170.103]) by smtp.gmail.com with ESMTPSA id g41sm15608626qtb.37.2020.06.28.05.34.34 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 28 Jun 2020 05:34:44 -0700 (PDT) Subject: Re: [RFC PATCH 3/3] add r_debug multiple namespaces support To: Florian Weimer , Carlos O'Donell via Libc-alpha References: <20200626193228.1953-4-danielwa@cisco.com> <87ftah5yh8.fsf@oldenburg2.str.redhat.com> <210c992f-b034-3ef7-440c-f67ab1b3acdb@redhat.com> <87366h5xmi.fsf@oldenburg2.str.redhat.com> <7e2fb426-cf03-a8e7-6524-a5f81fcf5b9e@redhat.com> <87ftagyhra.fsf@mid.deneb.enyo.de> Organization: Red Hat Message-ID: <8a15bd93-e4cc-a3bc-f902-5b3e701ec4e3@redhat.com> Date: Sun, 28 Jun 2020 08:34:32 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <87ftagyhra.fsf@mid.deneb.enyo.de> Content-Language: en-US X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit 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: Carlos O'Donell via Libc-alpha Reply-To: Carlos O'Donell Cc: Pedro Alves , Conan C Huang , Jeremy Stenglein , xe-linux-external@cisco.com Errors-To: libc-alpha-bounces@sourceware.org Sender: "Libc-alpha" On 6/27/20 5:34 AM, Florian Weimer wrote: > * Carlos O'Donell via Libc-alpha: > >> Truncated in which way? > > This part: > > | Your proposed solution of bumping the version is unacceptable, > | and was last rejected by Roland McGrath. The problem is that > | when you bump the version the current Thanks. "It's Friday" is my only excuse. I did provide some of the original links to the discussion. Roland, as a steward at the time, was worried about exactly what we see in gdb, which is "r_version != 1" may have made it into tooling. We can test this. We can try to deploy a similar solution in Fedora Rawhide and declare the semantics as we expect them to be. That is to say that r_version == 1, is the entire structure as we have it, and r_version == 2 *adds* but does not remove from the structure. Since the data is maintained by the implementation and the caller is only inspecting the data it should work. >> 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 you have a static executable you can get away with referencing _r_debug directly, but in that case symbol versions don't matter, and you have whatever version you have at the time. 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? If an application uses _r_debug, the symbol, directly, then they should get a static copy via the COPY relocation, and it will not be updated after that. Perhaps we can arrange for such an initial _r_debug to indicate it's not active or initialized? IMO the library should use a local-only reference to the _r_debug to avoid going through the global reference. I'm not keen to admit that a COPY reloc of _r_debug should work. -- Cheers, Carlos.