Re: [RFC PATCH]: Sparc gold support

[Ian Lance Taylor <iant at google dot com>]

David Miller <davem@davemloft.net> writes:

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

gold is intended to be driven mainly from the input files.  A
difference like this unfortunately can not be expressed solely in the
input files.

In GNU ld, as you say, it produces a different linker script.  The way
it's done in GNU ld right now is a little bit weird in that it doesn't
produce a different emulation.  The effect is that how you configure
GNU ld determines the default text address.  An ld configured for
Solaris and an ld configured for Linux will generate different
executables, even if you use a specific -m or -b option.

Doing it that way would be easy in gold: let configure.tgt add some -D
options to the compilation line, or something like that.

Doing it the right way, such that a single linker binary could
generate either Linux or Solaris executables, selectable by -m or -b,
would be harder.  But probably not that much harder.  To select by the
-b option, we would introduce a new Target_selector with a different
name.  Then the configure script would just have to specify which one
should be the default.

gold currently ignores the -m option.  As far as I know, the main
reason to recognize -m would be to support FreeBSD, which uses special
-m options to change the default interpreter name.  gold has nothing
like the full power of GNU ld emulations, but that's OK because nobody
uses them for ELF.  For gold -m would select a different Target.  We
would either conflate the -m and -b namespace, or we could introduce a
new function parallel to select_target_by_name.

I'm just throwing ideas out.  I don't have a clear idea of what the
best approach is here.


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

Yeah--gold is very weak on that right now.


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

Right, but the value() method is templated.  It's not a virtual
function, and it shouldn't be because that will increase the size of
the Symbol structure for no benefit.  So if you want to call value()
from a non-template function, then you need a test on size.  Which is
not particularly expensive--it will be a very predictable branch in a
given execution--but it's not entirely free either.

Actually you could also do it by setting up Target_sparc::Scan and
Target_sparc::Relocate to have virtual functions for the size.  Then
the subsidiary functions would not be template functions.

Ian