This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Possible different binutils version between GCC and GLIBC build


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]