This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [patch] STT_GNU_IFUNC support
- From: Mark Kettenis <mark dot kettenis at xs4all dot nl>
- To: jan dot kratochvil at redhat dot com
- Cc: gdb-patches at sourceware dot org
- Date: Sun, 14 Feb 2010 22:42:30 +0100 (CET)
- Subject: Re: [patch] STT_GNU_IFUNC support
- References: <20100214203512.GA838@host0.dyn.jankratochvil.net>
> 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.