From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from esa1.mentor.iphmx.com (esa1.mentor.iphmx.com [68.232.129.153]) by sourceware.org (Postfix) with ESMTPS id E85753858C00 for ; Fri, 19 May 2023 16:50:35 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org E85753858C00 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=codesourcery.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=mentor.com X-IronPort-AV: E=Sophos;i="6.00,177,1681200000"; d="scan'208";a="6620984" Received: from orw-gwy-01-in.mentorg.com ([192.94.38.165]) by esa1.mentor.iphmx.com with ESMTP; 19 May 2023 08:50:34 -0800 IronPort-SDR: vEnNA1xJebjGIxHMtMwdNVCKmS+wqyLZmHQMi4+3bpVMWPuHMbqtEnpErD0VaqJQ+DFN/wW0/m C4O4UmrH2ox8o7PL6g6MPJaDXEwgyGUhD03N1hGh98ZaRornUq52ZhomhDTQYya5VnFK4ayD2W JwCe7bd/vrfT/o3SM/qBIyeyFiqFu2a68I3Bc1oorsds8yx0L4q7jOH3cv35DFoNzxRULxa60w V7G3ZJk1pKAKGNpVyngplIzIJ8+dxyyRzbqcQ1dQ7XqZBef3oDYucZu//NZtzerLZ0zUwhsKiV WT0= Date: Fri, 19 May 2023 16:50:29 +0000 From: Joseph Myers To: Sergey Bugaev CC: Samuel Thibault , , Subject: Re: [RFC PATCH 06/10] hurd: Make sure to not use tcb->self In-Reply-To: Message-ID: References: <20230517191436.73636-1-bugaevc@gmail.com> <20230517191436.73636-7-bugaevc@gmail.com> <20230517205955.xb53s7fl5exydk2z@begin> <46ecbc3b-637c-9e52-516-ec2f706ac9dc@codesourcery.com> <33736439-2470-fe8e-d22f-5f6c444d2817@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Originating-IP: [137.202.0.90] X-ClientProxiedBy: svr-ies-mbx-14.mgc.mentorg.com (139.181.222.14) To svr-ies-mbx-11.mgc.mentorg.com (139.181.222.11) X-Spam-Status: No, score=-3106.6 required=5.0 tests=BAYES_00,HEADER_FROM_DIFFERENT_DOMAINS,KAM_DMARC_STATUS,SPF_HELO_PASS,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Fri, 19 May 2023, Sergey Bugaev via Libc-alpha wrote: > 'foo' is a public symbol, to be used by the user, and also > interposable by the user. Always called via PLT (except from inside > the user's code when redefined inside the executable, in which case > the compiler/linker will see that no PLT is needed), and should not be > called from inside glibc. Should not be called from within glibc via the PLT within the same library. It's OK for foo to be called from bar if foo is part of all the standards that contain bar. But in that case, if the call is from the same library, *_hidden_def / *_hidden_proto should be used to avoid calling via the PLT. If foo is not part of all the standards that contain bar, then glibc code for bar should use __foo instead to avoid namespace issues, especially for static linking. If __foo is needed by executables, *_nonshared.a or other shared libraries, then it also needs to be exported from the library it's in (in which case PLT avoidance is also relevant for __foo, so *_hidden_* should be used for __foo). If __foo is only used within a single library and doesn't need to be exported, it's OK to declare it directly with attribute_hidden rather than using *_hidden_* to create __GI___foo as an alias. (In this case, if you forget to use attribute_hidden, you won't get test failures - the symbol in fact won't get exported, because only symbols explicitly listed in the version maps get exported, and so it won't get a PLT entry. But in some cases, code generation is more efficient if the compiler knows that the symbol is hidden. So when you're calling an unexported symbol in the same library, it's still desirable for it to be declared as hidden in a way visible to the compiler.) The more complicated hidden_proto / hidden_def approach also works for unexported symbols used within a single library, it's just more complicated than necessary in that case. -- Joseph S. Myers joseph@codesourcery.com