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.2 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 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 1F9551F4B4 for ; Tue, 22 Sep 2020 18:44:50 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id EF13B398B8AE; Tue, 22 Sep 2020 18:44:48 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org EF13B398B8AE DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1600800289; bh=/F0LAOz3S7v8KaYPQ//TV5W7mmAVctAzbqPBB0BW66U=; h=To:Subject:References:Date:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=W4f6vRfNSLxY9/Ijt0hKhVjkHVwurqdNzARNeKtnXIN4FTB++m7DJykakkmIGC5RR Ks0v2asi7LXPmoHyKUOCTLk+Pwg/BQtSflSvv2VQJt9hWSyniDn3lbAqr9SGDCy1oG IOEGM9TFy6z8tRlp2thx1vy6xwQqg16bsyqZdhRE= Received: from us-smtp-delivery-1.mimecast.com (us-smtp-1.mimecast.com [205.139.110.61]) by sourceware.org (Postfix) with ESMTP id 98E793987502 for ; Tue, 22 Sep 2020 18:44:46 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 98E793987502 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-392-9CxIGnanOjSx1Ph_RdOugw-1; Tue, 22 Sep 2020 14:44:44 -0400 X-MC-Unique: 9CxIGnanOjSx1Ph_RdOugw-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 1017A801AE8; Tue, 22 Sep 2020 18:44:43 +0000 (UTC) Received: from oldenburg2.str.redhat.com (ovpn-114-108.ams2.redhat.com [10.36.114.108]) by smtp.corp.redhat.com (Postfix) with ESMTPS id CD30919C4F; Tue, 22 Sep 2020 18:44:38 +0000 (UTC) To: Carlos O'Donell Subject: Re: [RFC PATCH 0/3] implement dlmopen hooks for gdb References: <20200626193228.1953-1-danielwa@cisco.com> <0f791d3a-20bc-4524-54eb-ce6df108fbff@redhat.com> <20200723184054.GD9875@zorba> <3ff42e45-b394-bf50-38c4-93baecc71497@redhat.com> <87h7rpwxke.fsf@oldenburg2.str.redhat.com> <87y2l1vhkn.fsf@oldenburg2.str.redhat.com> <87h7rpvgb4.fsf@oldenburg2.str.redhat.com> <4b05c127-573a-2e9b-1147-18f827bfd07c@redhat.com> Date: Tue, 22 Sep 2020 20:44:37 +0200 In-Reply-To: <4b05c127-573a-2e9b-1147-18f827bfd07c@redhat.com> (Carlos O'Donell's message of "Tue, 22 Sep 2020 14:41:17 -0400") Message-ID: <87r1qttzvu.fsf@oldenburg2.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain 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: Florian Weimer via Libc-alpha Reply-To: Florian Weimer Cc: Pedro Alves , "xe-linux-external\(mailer list\)" , Carlos O'Donell via Libc-alpha , "Jeremy Stenglein \(jstengle\)" Errors-To: libc-alpha-bounces@sourceware.org Sender: "Libc-alpha" * Carlos O'Donell: > On 9/22/20 2:04 PM, Florian Weimer wrote: >> * Carlos O'Donell: >> >>>> No, unlike GLIBC_PRIVATE, you can assume that if a GLIBC_DEBUG symbol is >>>> there (and perhaps has the documented size), it has the documented >>>> semantics. But you can't assume that it is present. >>>> >>>> The semantics of GLIBC_PRIVATE symbols can change arbitrarily, even >>>> between builds. >>> >>> Yes, absolutely, I agree completely, for it to be useful the semantics >>> have to be: >>> >>> - If you detect a given symbol foo@GLIBC_DEBUG, then the feature is >>> present and has the semantics you expect. >>> >>> - If you want new semantics then you need to make a foo2@GLIBC_DEBUG >>> with the new semantics. >>> >>> What are the runtime semantics of the symbol? How do you access it? >> >> That obviously depends on the symbol? Sorry, I don't quite understand >> these questions. > > You noted "not intended to be used for run-time linking?" > > Could you expand on what you're thinking there? If there are no versioned dependencies on the symbol at the ELF level, then the issues that require some distributions to backport whole symbol sets do not apply. The exact contents of the GLIBC_DEBUG symbol set does not matter than. Thanks, Florian -- Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill