Re: ld -r frustration

[Alan Modra <amodra at bigpond dot net dot au>]

Thanks for all your replies.

On Tue, Jul 27, 2004 at 10:47:46AM -0700, Zack Weinberg wrote:
> Richard Earnshaw <rearnsha@gcc.gnu.org> writes:
> > Well on ELF you can just write out every section unchanged in a single
> > object file (ELF is quite happy to have multiple sections with the same
> > name, it's only GAS that doesn't know how to do this).  IIRC the only
> > thing that needs merging is the symbol table.
> >
> > It's then a genuine object file and you don't need to frob the linker at
> > all.
> 
> It seems to me that the Right Thing is to make ld -r on PowerPC64
> not merge TOC sections when this would cause overflow.  Final link
> can do this, so I don't see why ld -r can't.

The thing is that I need to keep a mapping between chunks of code and
chunks of TOC, so that the linker can insert TOC pointer adjusting stubs
on calls between functions that use different TOC pointers.  The current
scheme uses the natural "chunk" of an input object file.  ld -r loses
that mapping for me, even if I keep the original TOC sections.  (And we
potentially have zillions of code sections being merged on ld -r if
-ffunction-sections was used when compiling.)  I really don't want to
undo a ld -r..

On Tue, Jul 27, 2004 at 04:56:54PM +0100, Dave Korn wrote:
> b) get libtool to use "ar cr" as standard,
> c) add a bit to the docs explaining why, if you want an archive of object
> files, you should use an archive, and not a partial link, which is a far
> more complex transformation, rather than a mere innocuous bundling-together.
> 
>   IOW, I think it's the user expectations that are wrong here.	

Agreed.  I tried at one stage to fix libtool, but met resistance from a
libtool maintainer.

I think I'll just make ld -r return an error if the TOC overflows.

Incidentally, one of the nasty effects of ld -r on any arch is the fact
that it can reorder code.  eg. If compiling with -ffunction-sections,
all static functions called "setup" in different files will be grouped
into the one section.  This loses code locality and can affect cache
performance.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre