Re: [RFC PATCH]: Sparc gold support

[David Miller <davem at davemloft dot net>]

From: Ian Lance Taylor <iant@google.com>
Date: Mon, 14 Apr 2008 15:39:43 -0700

Thank you for reviewing.

> Are there really little-endian SPARC targets?  A lot of the target
> code is templated on big_endian, but there is no little-endian
> selector or Target_info structure.

Yes, they exist and I intend to instantiate them once I work out
the details.  For example, for sparclite and sparc86x.

In fact it's even more complicated.  Because it turns out that one
has big-endian instructions and little-endian data, while the other
has both little-endian instructions and data.

Luckily I think the instruction endianness issues can be contained to
the relocation functions.

This reminds me that we have the issue that Linux and Solaris use the
same OS/ABI indicator in the ELF header, but Solaris uses a different
default text start address.  So you can't just look at the input
objects and figure out what to use.

These are the kinds of things that were resolved by linker scripts in
the BFD linker.  It seems that one of the goals of gold is to work
by default without a linker script, so it would be nice to have a way
to resolve these kinds of problems without one.

Any ideas?

> The dst_mask variants of the relocation function should perhaps be in
> reloc.h.

Perhaps.  Also, one area I want to improve things is overflow
detection and handling.

> I wouldn't worry about the size of the generated code.  There isn't a
> lot of straight duplication there.  The functions all do some work
> that is size specific.  Any given link is only going to use one size,
> so there aren't any instruction cache issues here.  Anything you do to
> reduce the amount of generated code is going to slow down the linker a
> tiny little bit when you eventually switch on the size.

I'm not so sure.  I had some ideas wrt. providing routines that work
on the non-sized variants.

If you look at the target code in question, it really doesn't care
about the size of the types.  The target code is simply acting like
a bridge between the generic relocation processing and the functions
that apply relocations.

They largely don't care what kind of Symbol or Output_section they
have.  They just want to, f.e., resolve the symbol's address by
calling it's ->value() method.

> So reducing the generated code would just save executable file size
> at the cost of runtime.

I think it could be done without runtime costs.  I'm sensitive to
runtime costs, don't worry :-)

> The executable file is about 1.5M, and you couldn't save much of
> that.  So overall I wouldn't worry about it.

Stripped and built with "-O2", the sparc target with both 32-bit and
64-bit big-endian instantiated enabled is:

-rw-r--r-- 1 davem davem 148904 Apr 14 15:59 sparc.o

with only the 64-bit big-endian target instantiated it is:

-rw-r--r-- 1 davem davem 89464 Apr 14 16:00 sparc.o

That's a nearly doubling in size just by instantiating two target
variants instead of one.

It's going to double again when the various little-endian
targets get instantiated too.

I think it's worth pursing improvements here, even as a low
priority task.  When I combined the two BFD sparc backends
largely into bfd/elfxx-sparc.c, size was my main impetus.