Re: symbol type in ->check_relocs()

[Alan Modra <amodra at gmail dot com>]

On Tue, Feb 02, 2010 at 02:34:53PM -0800, David Miller wrote:
> From: Alan Modra <amodra@gmail.com>
> Date: Wed, 3 Feb 2010 08:26:01 +1030
> > So anything you need to do for ifunc syms, you need to do for undef
> > ones.
> 
> How can it?
> 
> 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.  ;-)

> 
> These functions handle STT_GNU_IFUNC relocations properly only when
> the h->type is set to it's final resting value.
> 
> 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?

-- 
Alan Modra
Australia Development Lab, IBM