This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Expand PIC calls without PLT with -fno-plt
- From: Rich Felker <dalias at libc dot org>
- To: Michael Matz <matz at suse dot de>
- Cc: "H.J. Lu" <hjl dot tools at gmail dot com>, Alexander Monakov <amonakov at ispras dot ru>, Jakub Jelinek <jakub at redhat dot com>, Jeff Law <law at redhat dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Mon, 11 May 2015 10:19:39 -0400
- Subject: Re: [PATCH] Expand PIC calls without PLT with -fno-plt
- Authentication-results: sourceware.org; auth=none
- References: <20150506154554 dot GZ1751 at tucnak dot redhat dot com> <alpine dot LNX dot 2 dot 11 dot 1505061939240 dot 22867 at monopod dot intra dot ispras dot ru> <20150506173521 dot GJ17573 at brightrain dot aerifal dot cx> <CAMe9rOqDZyY-UTb8xW4OM7ZbW7p_W5w7Vk7Pbh07vAechqj2Nw at mail dot gmail dot com> <20150506183735 dot GK17573 at brightrain dot aerifal dot cx> <CAMe9rOoxbn33SwXCmHcwYL87t4_JgxgHtT6HSECtFguyLQpxKw at mail dot gmail dot com> <20150506190128 dot GL17573 at brightrain dot aerifal dot cx> <CAMe9rOokRzVkeaaeXYwFhnPLjnfKw+QUiJC1nEgGM05fDy-zMQ at mail dot gmail dot com> <20150506191750 dot GM17573 at brightrain dot aerifal dot cx> <alpine dot LSU dot 2 dot 20 dot 1505111342150 dot 4883 at wotan dot suse dot de>
On Mon, May 11, 2015 at 01:48:03PM +0200, Michael Matz wrote:
> Hi,
>
> On Wed, 6 May 2015, Rich Felker wrote:
>
> > I don't see how this case is improved unless GCC is failing to consider
> > strong definitions in the same TU as locally-binding.
>
> Interposition of non-static non-inline non-weak symbols is supported
> independend of if they are defined in the same TU or not (if you're
> producing a shared lib, that is). I.e. no, they are not considered
> locally-binding (for instance, they aren't automatically inlined).
>
> > If this is the case, is there a reason for that behavior?
>
> Because IMHO interposition is orthogonal to TU placement, and hence
> shouldn't be influenced by it. There's visibility, inline hints or
> static-ness to achieve different effects. (perhaps the real reason is:
> because it always worked like that :) )
>
> > IMO it's wrong.
>
> Why? I think it's right.
I see it as an unnecessary pessimization. The ELF shared library
semantics for allowing interposition were designed to avoid behavioral
regressions versus static linking, and this is not such a case. With
an archive-type library, it's possible to cause whole TUs to be
omitted when linking as long as whatever symbol(s) may have been
needed from them are already defined elsewhere; interposition makes
the same possible with dynamic linking. But if symbols A and B were
both in the same TU, having A defined prior to searching an archive
but B undefined will cause the TU that defines both to be pulled in,
and is such a linking error (multiple definitions). So I'm not sure
why it's desirable to support this.
The "it always worked like that" argument may suffice if people are
depending on this behavior now (OTOH I'd rather see it break so they
fix their breakage of static linking) but I suspect the historical
reason it worked like that is that compilers were not smart enough to
process whole TUs at a time but just worked with one function at a
time and did not know that a referenced symbol was in the same TU.
BTW visibility can't really address the issue except with hacks
(hidden aliases) or protected visibility (which is hard to use because
it's broken on lots of toolchain versions).
Rich