From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <hjl.tools@gmail.com>
Received: from mail-pj1-x1033.google.com (mail-pj1-x1033.google.com
 [IPv6:2607:f8b0:4864:20::1033])
 by sourceware.org (Postfix) with ESMTPS id A2D603839C6C
 for <binutils@sourceware.org>; Fri, 18 Jun 2021 02:42:14 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org A2D603839C6C
Received: by mail-pj1-x1033.google.com with SMTP id
 x21-20020a17090aa395b029016e25313bfcso5008664pjp.2
 for <binutils@sourceware.org>; Thu, 17 Jun 2021 19:42:14 -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=zIHW7oh4NBbWpbCZs6KPG1wIoXD9lHKANvlFE55HLW8=;
 b=OUfCR9N4IvGkpRhThfNrl1EyhrXW5nl7QRmUi5d5rYjtSNm3CHpM3b7SxLzus4R8mq
 xXs5GDn6REsSFckl7JorYXr124xM1O3MYLiV/1AIzXIvo5lpxDeXJAchbs7FTyJnjiIN
 Zwlq46NhLp5qO7o4nQ9FhEuv7Vp64Mb1N99QdgkBNdN93mmdfbCFM4op81n5gKIZdVr2
 tB9FxVN2DUe119Y0yZMxjdTNhF/Kk8/IKTcKj2+nemvfxYZqb82qoqbgwhEn/krZjsW1
 PGNincjQcG6sTdAU6Q2mA0UrXkYqXiOWZ4Zte6I8fywJqKfj4bQ2aK+7bZGstTgY2w1O
 BduA==
X-Gm-Message-State: AOAM531CKHIw4QJBuehLin0LEC5iBSPEPxTDpW6m4Qna34jK/CNWZYDg
 +4brb+QZYmwqHZNKHVsJkSf4VaT+VIvRpVFIkCA=
X-Google-Smtp-Source: ABdhPJxLxu61WJiYAsdCNXgIOs89fAdxH/PKPceDwm0v7zBNPQkOWjVN6vzRNeRwm0jCDiRuL5+ZyeKKTbbK/mp3LI8=
X-Received: by 2002:a17:90b:10e:: with SMTP id
 p14mr2453406pjz.153.1623984133882; 
 Thu, 17 Jun 2021 19:42:13 -0700 (PDT)
MIME-Version: 1.0
References: <20210614174336.4g4gesqc6nxnmho4@gmail.com>
 <YMgUf+5IIQxe2cjX@bubble.grove.modra.org>
 <20210615031932.i4g36e4bmwplsgoi@gmail.com>
 <YMl1yQGLs7wjNK6T@bubble.grove.modra.org>
 <20210616044217.6coujfcfpvz2de5h@gmail.com>
 <YMma1E3SzMyB0izK@bubble.grove.modra.org>
 <20210616081143.befkfjzdqvybjpbz@gmail.com>
 <YMq6dsQIsXGAouMP@bubble.grove.modra.org>
 <20210617042404.cdojdbmlage6bw7y@gmail.com>
 <CAMe9rOqWJa2FwE0F+Gc3rgRDV7k9yB=rv6hUEWubrzspsqWC+w@mail.gmail.com>
 <YMv8z84Uc412ktmJ@squeak.grove.modra.org>
In-Reply-To: <YMv8z84Uc412ktmJ@squeak.grove.modra.org>
From: "H.J. Lu" <hjl.tools@gmail.com>
Date: Thu, 17 Jun 2021 19:41:37 -0700
Message-ID: <CAMe9rOqPa0QaJaRgjqnU5PY0kMUCWG_ghVsQ3N_1M0c7ALaEUg@mail.gmail.com>
Subject: Re: [PATCH] Allow direct access relocations referencing a protected
 function symbol
To: Alan Modra <amodra@gmail.com>
Cc: Fangrui Song <i@maskray.me>, Cary Coutant <ccoutant@gmail.com>,
 Michael Matz <matz@suse.de>, 
 Florian Weimer <fweimer@redhat.com>, Szabolcs Nagy <szabolcs.nagy@arm.com>, 
 "binutils@sourceware.org" <binutils@sourceware.org>,
 Fangrui Song <maskray@google.com>
Content-Type: text/plain; charset="UTF-8"
X-Spam-Status: No, score=-3026.0 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 autolearn=ham autolearn_force=no version=3.4.2
X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on
 server2.sourceware.org
X-BeenThere: binutils@sourceware.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Binutils mailing list <binutils.sourceware.org>
List-Unsubscribe: <https://sourceware.org/mailman/options/binutils>,
 <mailto:binutils-request@sourceware.org?subject=unsubscribe>
List-Archive: <https://sourceware.org/pipermail/binutils/>
List-Post: <mailto:binutils@sourceware.org>
List-Help: <mailto:binutils-request@sourceware.org?subject=help>
List-Subscribe: <https://sourceware.org/mailman/listinfo/binutils>,
 <mailto:binutils-request@sourceware.org?subject=subscribe>
X-List-Received-Date: Fri, 18 Jun 2021 02:42:16 -0000

On Thu, Jun 17, 2021 at 6:54 PM Alan Modra <amodra@gmail.com> wrote:
>
> On Thu, Jun 17, 2021 at 10:25:09AM -0700, H.J. Lu wrote:
> > On x86-64, function pointers in executable for external funtions may be
> > resolved to their PLT entries in executable.  If it happens, function
> > pointers of protected funtions in shared libraries must be resolved to
> > the PLT entries in executable, not addresses of protected funtions in
> > shared libraries.
>
> Yes, but quite plainly we have a broken toolchain at the moment.  With
> correct options for generating shared library code, gcc generates
> objects that ld.bfd refuses to link.  That's BAD.  At a minimum the ld
> error needs to be reduced to a warning, but preferably silenced.
>
> What's more, function pointer comparisons work in many cases when the
> executable is a PIE, even on x86.  For example
>
> library:
> void __attribute__ ((visibility ("protected")))
> protfun (void) { __builtin_printf ("Address in lib is %lx\n", (long) &protfun); }
>
> executable:
> extern void protfun (void);
> int main (void)
> {
>   __builtin_printf ("Address in main is %lx\n", (long) &protfun);
>   protfun ();
>   return 0;
> }
>
> And this variant of the executable
>
> extern void protfun (void);
> void *const addr = &protfun;
>
> int main (void)
> {
>   __builtin_printf ("Address in main is %lx\n", (long) addr);
>   protfun ();
>   return 0;
> }
>
> only fails when PIE due to ld.bfd needlessly emitting a dynamic
> protfun symbol with non-zero value.  It's not needed when the const
> "addr" is in .data.rel.ro, a writable section when ld.so is
> relocating.

I want to address this once for all.

-- 
H.J.