Possible different binutils version between GCC and GLIBC build

Possible different binutils version between GCC and GLIBC build

[Adhemerval Zanella]

Checking on sysdeps/sparc/configure.ac I noticed a possible cleanup
by removing HAVE_GCC_GOTDATA, which is not used anywhere in code. 
However the libc_cv_sparc_gcc_gotdata is a little more tricker
because it relies on gcc support instead.

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.

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.

Re: Possible different binutils version between GCC and GLIBC build

[Joseph Myers]

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.

> 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.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Possible different binutils version between GCC and GLIBC build

[Adhemerval Zanella]

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

Re: Possible different binutils version between GCC and GLIBC build

[Joseph Myers]

On Wed, 29 Nov 2017, Adhemerval Zanella wrote:

> code paths for the loader.  It also states about a MIPS bug related to
> it, but I couldn't find more information about it.

I think it's referring to:

https://sourceware.org/ml/libc-alpha/2015-03/msg00704.html
https://sourceware.org/ml/libc-alpha/2016-10/msg00476.html
https://sourceware.org/ml/libc-alpha/2016-11/msg00008.html

(as far as I know the last of those patches still needs review).

-- 
Joseph S. Myers
joseph@codesourcery.com