Re: [patch] STT_GNU_IFUNC support

[Mark Kettenis <mark.kettenis@xs4all.nl>]

> Date: Sun, 14 Feb 2010 21:35:12 +0100
> From: Jan Kratochvil <jan.kratochvil@redhat.com>
> 
> STT_GNU_IFUNC is defined in OS-specific range:
> 
> #define STT_LOOS        10      /* OS-specific semantics */
> #define STT_GNU_IFUNC   10      /* Symbol is an indirect code object */
> #define STT_HIOS        12      /* OS-specific semantics */
>
> ... 
> 
> Due to the function descriptors similarity I had to hook it into the OSABI
> framework which does not support any inheritance.  Single OSABI is chosen.
> gnu-ifunc is only OS-dependent (GNU) and not arch dependent, though.
> Therefore gnu-ifunc had to be hooked into all the OS-ARCH combinations where
> the GNU OS gets installed as OSABI (=> *-linux-tdep.c).

While the symbol may be in the OS-specific range it is actually more
toolchain dependent than OS-dependent.  Unless I'm missing something,
all OS'es that use binutils as their toolchain will support
STT_GNU_IFUNC.  In particular, I expect the various BSD's to
eventually support this too, and I found a Google groups discussion
that said that while Sun^H^H^Oracle has no immediate plans to support
this extension, they may eventually do and will reserve the slot
occupied by STT_GNU_IFUNC in the STT_LOOS-STT_HIOS range.

This has happened before with GNU extensions.  OpenBSD/sh supports
some GNU-specific ELF relocations and I personally added support for
PT_GNU_EH_FRAME to OpenBSD to make DWARF-based exception handling work
on several OpenBSD platforms.

So I think you should move the gnu-ifunc support code out of
linux-tdep.c into a more generic file.  And perhaps we should consider
enabling support for it on all supported ELF platforms.  Given that
Sun is aware of STT_GNU_IFUNC, I don't think there is a serious risk
of another OS vendor using the value occupied by STT_GNU_IFUNC for a
different purpose.