Re: gold's target->make_symbol()

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

David Miller <davem@davemloft.net> writes:

> For example, for STT_REGISTER symbols there is a NULL "" name attached
> to every symbol for registers being used as scratch values.  The
> distinguishing factor is that the "value" which indicates which global
> register is being referenced.
>
> Currently if you use a normal symbol gold is just going to obliterate
> the STT_REGISTER symbols other than the first one.  We don't want
> that, we want to collect all of the STT_REGISTER symbols with
> different st_value fields, validate them, and propagate them into
> the output file as necessary.
>
> I guess your ideas come from situations like SHN_X86_64_LCOMMON, which
> is more in line with traditional symbol handling.

OK, I looked up STT_REGISTER symbols.

The description in the Sun Linkers and Libraries Guide is terse, but
it does seem like we want to take these symbols entirely out of the
normal processing loop.  Since we can assume that there won't be very
many of them, perhaps the SPARC backend should manage them completely.

Still, I'm now thinking that we should not call the make_symbol hook
for all symbols.  We should only call it for symbols of unknown type.
It can return NULL if there should not be an entry in the symbol
table.  We shouldn't call it from define_special_symbol at all, as you
suggested.

Of course, with this approach we will also need a target hook to add
symbols to the symbol table at output time.  And we would need
something special to handle R_SPARC_REGISTER relocations against
STT_REGISTER symbols.

The other possibility I see would be to implement STT_REGISTER symbols
by giving them a unique name.  But that doesn't sound right to me.

Ian