symbol type in ->check_relocs()

[David Miller]

From: Alan Modra <amodra@gmail.com>
Date: Wed, 3 Feb 2010 09:35:16 +1030

> On Tue, Feb 02, 2010 at 02:34:53PM -0800, David Miller wrote:
>> Look even at the elf64-ppc.c ->check_relocs() code.  It specifically
>> does all of it's "ifunc = &h->plt.plist" business only when h->type ==
>> STT_GNU_IFUNC.
>> 
>> And therefore, for example, without h->type being STT_GNU_IFUNC this
>> code also will not invoke update_plt_info().
> 
> Nope.  For global symbols you'll see later that we call
> update_plt_info just after "if (h != NULL && ifunc == NULL)".  Hmm,
> actually there may be a bug there for ADDR24 and ADDR14 relocs which
> in one case get a plt entry and in the other a dynamic reloc.  Oh
> well, those relocs don't appear in gcc output.  ;-)

What about local symbols.... you won't emit things properly
in that case.

I sincerely think this can't all be handled properly as-is.

> On Tue, Feb 02, 2010 at 02:34:53PM -0800, David Miller wrote:
>> I really think ->check_relocs() mustn't make tests on the value of
>> h->type in any way, and that only future passes which execute after
>> all symbol resolution has occurred are allowed to do so.
> 
> Well, ifunc needs a plt entry.  If you don't specially treat defined
> ifunc syms, are you going to do plt ref counting on all defined syms?

Well, another approach is to do ->check_relocs() processing after
we've read all of the symbol tables in.

But that would make some forms of TLS relocation validation no
longer feasible (for example, catching that something is accessed
as both a normal and thread local symbol).

The more I work on STT_GNU_IFUNC support, the more adhoc the
implementation in the backends feels. :-)