Re: PPC sdata problems

[Momchil Velikov <velco at fadata dot bg>]

Geoffrey Keating <geoffk@geoffk.org> writes:

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

That "used to work" must have been long time ago:

http://sources.redhat.com/ml/binutils/2001-02/msg00444.html
http://sources.redhat.com/ml/binutils/2000-04/msg00005.html