public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Cary Coutant <ccoutant@gmail.com>
To: Sriraman Tallam <tmsriram@google.com>
Cc: binutils <binutils@sourceware.org>,
	Paul Pluzhnikov <ppluzhnikov@google.com>,
		Rong Xu <xur@google.com>, Brooks Moses <bmoses@google.com>,
	Ollie Wild <aaw@google.com>, 	David Li <davidxl@google.com>,
	Teresa Johnson <tejohnson@google.com>,
		"H.J. Lu" <hjl.tools@gmail.com>,
	Ian Lance Taylor <iant@google.com>
Subject: Re: Patch to not create GOT and dynamic relocation entries for unresolved symbols with --warn-unresolved-symbols.
Date: Sat, 11 Apr 2015 02:18:00 -0000	[thread overview]
Message-ID: <CAJimCsG4yZAA1o-_nVEWH=9DwBjQZiCwDGQzNcDa+GY_XbMwvw@mail.gmail.com> (raw)
In-Reply-To: <CAAs8Hmxe3fNV-7MLyNhk_=DOaR91-s=dFw3E-cFdqCCiGxxreA@mail.gmail.com>

> However, with -fPIE
>
> $ g++ -O2 -fPIE foo.cc -pie
> foo.cc:function main: warning: undefined reference to 'foo()'
>
> but
> $./a.out
> ./a.out: symbol lookup error: ./a.out: undefined symbol: _Z3foov
>
> because with fPIE, a function pointer access is using a GOTPCREL
> relocation which creates a GOT entry and a dynamic relocation for it.
> The dynamic linker does not like the unresolved symbol any more.
>
> I have attached a patch to prevent creation of GOT and dynamic
> relocation entries with --warn-unresolved-symbols in general.  Is this
> reasonable?

No, I don't think so. For static links, we statically resolve
undefined symbols to zero, but for non-static links, we leave them for
dynamic resolution, presuming that they might be resolvable at
runtime. This patch would change linker behavior that is fairly well
established. (This patch also changes only x86_64 behavior; you'd need
a similar patch for all targets. For a problem that isn't really
target-specific, I'd prefer a target-independent solution.)

The difference between non-PIE and PIE here is not due to the linker's
-pie option, but because the compilers -fPIE option caused the
compiler to use the GOTPCREL relocation, which requires the linker to
create a GOT entry.

If the reference to foo is weak, the dynamic loader won't complain --
I think that's really what you want. I'm not sure whether it's
reasonable for you to have the compiler make these symbols weak unsats
or not, but if you can, you wouldn't need --warn-unresolved-symbols
any longer. If not, I wouldn't object to a new
--weak-unresolved-symbols option that would have the linker convert
any unresolved symbols (that it warned about) into weak references. I
don't think we want to do that by default, since it changes existing
expectations, but I think it's fine as an option.

HJ, does that sound like a reasonable option for Gnu ld as well?

-cary

  parent reply	other threads:[~2015-04-11  2:18 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-11  0:16 Sriraman Tallam
2015-04-11  0:22 ` Sriraman Tallam
2015-04-11  2:18 ` Cary Coutant [this message]
2015-04-11 13:28   ` H.J. Lu
2015-04-20 23:06     ` Sriraman Tallam
2015-04-22 19:33       ` Cary Coutant
2015-04-23 15:09         ` Cary Coutant
2015-04-23 17:27           ` Sriraman Tallam
2015-04-23 18:01             ` Cary Coutant

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAJimCsG4yZAA1o-_nVEWH=9DwBjQZiCwDGQzNcDa+GY_XbMwvw@mail.gmail.com' \
    --to=ccoutant@gmail.com \
    --cc=aaw@google.com \
    --cc=binutils@sourceware.org \
    --cc=bmoses@google.com \
    --cc=davidxl@google.com \
    --cc=hjl.tools@gmail.com \
    --cc=iant@google.com \
    --cc=ppluzhnikov@google.com \
    --cc=tejohnson@google.com \
    --cc=tmsriram@google.com \
    --cc=xur@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).