Re: PPC sdata problems

[Geoffrey Keating <geoffk at geoffk dot org>]

Daniel Jacobowitz <drow@false.org> writes:

> Normally, the symbol _SDA_BASE_ is defined by the crti.o GCC produces.  As
> far as I can tell, this puts it at the beginning of .sdata, which limits you
> to about half the size sdata could normally be; am I missing something
> there?
> 
> There's code in the linker to create _SDA_BASE_ if it doesn't already exist,
> but it doesn't work if the first file in your link has small data.  It will
> check for .sdata, find that it already exists, check its flags:
>   flags = SEC_ALLOC | SEC_LOAD | SEC_HAS_CONTENTS | SEC_IN_MEMORY;
> ...
>   s = bfd_get_section_by_name (htab->elf.dynobj, name);
>   if (s == NULL || (s->flags & flags) != flags)
> 
> This always fails because of the SEC_IN_MEMORY check.  Then we create a
> second section in dynobj named .sdata, but it ends up emitted after the
> existing .sdata section; and we create _SDA_BASE_ relative to the beginning
> of that section, so nothing in the first file's .sdata section can be
> addressed.  The relocations overflow.
> 
> There's a number of possible fixes for this.  My favorite is to not check
> the flags; just use the provided .sdata and .sdata2 sections in dynobj if
> there are any.  Thoughts?

The features you're looking for used to work, so something must have
changed to break them...