This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: PPC sdata problems
- From: Geoffrey Keating <geoffk at geoffk dot org>
- To: Daniel Jacobowitz <drow at false dot org>
- Cc: binutils at sources dot redhat dot com
- Date: 16 Jun 2004 13:03:43 -0700
- Subject: Re: PPC sdata problems
- References: <20040616190921.GA4857@nevyn.them.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...