From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi1-x231.google.com (mail-oi1-x231.google.com [IPv6:2607:f8b0:4864:20::231]) by sourceware.org (Postfix) with ESMTPS id 027123858D39 for ; Fri, 19 May 2023 08:22:22 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 027123858D39 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-oi1-x231.google.com with SMTP id 5614622812f47-392116b8f31so1108457b6e.2 for ; Fri, 19 May 2023 01:22:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1684484541; x=1687076541; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=66FxUojJTafMdOZZtdEf8ejNF5hOtMdRL+Sg+dXb+Qg=; b=F/cvohPCLdVE3TfDlx0qG/P7Uo8s2TFJTY3cFLIJ9XwfD45B+uIS9FnoGqiF8Dnuyq MI1Dbsh2B/OlQ73cqnU7m0OngFiBadiBpC/ocP1BdCRw4WU/a/oyZGadDx9ccpghdZA/ N/+KI11/KB2EYQi50E5/5Akkxue0WplzikQo8wG+xdrxB9qdJ5Qo/010YFun5WMGGDuc 0h1preRTJbUkruEdlM96+r5CtBTDMSxgIVwNj3pTPQYG2+nV/AsGZp0rC87YSvp8iFZz 7H5dRrlYsU6f7VJvHtHYCfXPg3Ch51D/kmqPbq3MZQx7ev0ecYXlmZgonI+Cu1u1Ei+H qJeg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684484541; x=1687076541; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=66FxUojJTafMdOZZtdEf8ejNF5hOtMdRL+Sg+dXb+Qg=; b=UK6HgUoONOO0filIE9UQ1iYqIIxsCrBRhoQOz0TfzUygFiQiKXlzm7WcqygKBHafL/ cDGD9SfyVvcLEi3DffY5BmEgEUR5pPnCJ2WEdNzW27S4dAukLX3dDRromVLtv8uVQYxH 8QOH28O6qaupRjsv5d6nDa9L16Xd6a5iUAxEDZKCTZHBtz6KLA98EqrUGT7I1usdV93M 0ooBAdc/VTEqCNk2C2nOkV6Q25ZWI0NMXhTNGfxj2zQlml+lk4FcW9M47NpLL5eWvq+P UmF1ZL2cwictO1dcL6bMDGvIYz8IeMaFgn2D4ENNKFSQl8CSzCV8V7e8dd72cU9mpZAa 3Ctw== X-Gm-Message-State: AC+VfDyqxehjMUr2BoGGv79JDEhGS5huH5VfcUCudn+roC/9HuraOhmJ vvvvV0n4IWdTGLqYJjDSjqJgwVPdTTZgoy0fTKXanNJD9l4= X-Google-Smtp-Source: ACHHUZ5vMbREfYxllD+vdxTyx0yARE/4wGFpuFtFB3bo9HOG16V7Pfbi1aUoXvYv+Hye/4Oa/nzUnf8wLeousUecirc= X-Received: by 2002:aca:1a12:0:b0:396:305b:e3c0 with SMTP id a18-20020aca1a12000000b00396305be3c0mr602252oia.29.1684484541233; Fri, 19 May 2023 01:22:21 -0700 (PDT) MIME-Version: 1.0 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> In-Reply-To: <33736439-2470-fe8e-d22f-5f6c444d2817@codesourcery.com> From: Sergey Bugaev Date: Fri, 19 May 2023 11:22:10 +0300 Message-ID: Subject: Re: [RFC PATCH 06/10] hurd: Make sure to not use tcb->self To: Joseph Myers Cc: Samuel Thibault , libc-alpha@sourceware.org, bug-hurd@gnu.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE,URIBL_BLACK 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 Thu, May 18, 2023 at 11:16=E2=80=AFPM Joseph Myers wrote: > Strictly there are two separate issues: (a) calling an exported symbol > should be done via a hidden alias, to avoid going via the PLT, and (b) > functions in a standard namespace should not call names in the user's > namespace, which requires using a name such as __hurd_thread_self instead > (which should also be marked hidden to make the call optimally efficient)= . While we're talking about this, could you please say if my understanding below is correct (and correct me if not)? '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. '__foo' is a (public? private? semi-private?) symbol, the user code is not supposed to use it, but it's exported from libc.so for the benefit of other glibc code that ends up in different DSOs and still wants to call the original version even when 'foo' gets interposed. Invoked via PLT from other DSOs, not invoked from libc.so because of... '__GI___foo' is a private non-exported symbol created by the hidden_def/hidden_proto macro being used on '__foo', this is what the code in libc.so (or: whatever DSO the symbol is hidden_def'ed in) calls to avoid PLT jumps. Q: why '__foo', why not use hidden_def/hidden_proto on the 'foo' directly? A: that would only work for code that ends up in libc.so (or rather, the same DSOs as 'foo'), but we still want other code to also call the non-interposed, original version of 'foo' Is that ^^ correct? Should each and every function that is exported to the user and also used inside libc's own code have '__foo' and '__GI___foo' versions? What does 'GI' even stand for? Thanks in advance, Sergey