Re: Possible different binutils version between GCC and GLIBC build

[Adhemerval Zanella <adhemerval dot zanella at linaro dot org>]

On 29/11/2017 12:26, Joseph Myers wrote:
> On Wed, 29 Nov 2017, Adhemerval Zanella wrote:
> 
>> SPARC have support for GOTDATA since binutils 739f7f82be (binutils
>> 2.19), however GCC will have support for gd{op,lo}_hix22 depending
>> of the used binutils on its build and as far I could check it does
>> not really imposes a minimum version, but rather it works with
>> features provided by the linker.  So in theory we could have a gcc
>> configured with an older binutils without support for GOTDATA and
>> at same time build GLIBC with a newer one.
>>
>> How should we proceed in this cases? The main driver is to try
>> cleanup the configure so we can assume PI_STATIC_AND_HIDDEN on
>> all architectures.  SPARC support is conditional to GOTDATA
>> support and MIPS has a comment stating GCC has no support for it.
> 
> Well, you could define a minimum binutils version GCC was configured with, 
> but then you'd need a configure test for that to give an error if the 
> version was too old, which presumably would be a feature test much like 
> the present one.

I though about that and in the end it won't be a cleanup. In any
case I think we can clean up the HAVE_GCC_GOTDATA definition at least.

> 
>> As a side note, is still true for MIPS? I noted for the very
>> example used on SPARC to check for GOTDATA support I noted a
>> recent MIPS GCC (gcc 6.2.1 / ld 2.27) does emits got relocations
>> to access local variables.
> 
> I'm not clear what exactly you're testing.  The SPARC test doesn't appear 
> to involve hidden visibility, even if in fact it's sufficient to test 
> what's required in the SPARC GCC case.  As I understand it, the relevant 
> thing for PI_STATIC_AND_HIDDEN is that a hidden-visibility object, in code 
> compiled with PIC, will be accessed in a way that does not involve a GOT 
> entry - it may still involve relocations, but those relocations will be 
> resolved at static link time.
> 
> There are lots of architectures with no definition of PI_STATIC_AND_HIDDEN 
> at all, quite possibly with ABIs not providing suitable static relocations 
> for non-GOT PI accesses to hidden-visibility symbols.  In the MIPS case, 
> for all ABIs I see code generated that computes the global pointer, and 
> the offset of a GOT entry from that, before dereferencing the address of 
> that GOT entry.
> 
> Note that all MIPS n64 code, in the absence of -msym32, computes addresses 
> using GOT entries, simply because it would be less efficient (even in code 
> that can be position-dependent) to build up a 64-bit address piece by 
> piece with a series of instructions.
> 

Alright, thanks for the explanation. It seems that PI_STATIC_AND_HIDDEN 
still have usage.  I was somewhat driven by the information in the
thread which Roland enabled it for ARM [1], which both the performance
difference and code side did not show much gain in having two different
code paths for the loader.  It also states about a MIPS bug related to
it, but I couldn't find more information about it.

[1] https://sourceware.org/ml/libc-alpha/2015-04/msg00209.html