Richard,
On Wed, 2010-11-17 at 17:12 +0000, Richard Sandiford wrote:
The STT_GNU_IFUNC blueprint:
https://wiki.linaro.org/WorkingGroups/ToolChain/Specs/Binutils-STT_GNU_IFUNC
says "the ARM EABI will be updated to support STT_GNU_IFUNC's requirements". I suppose the most obvious thing that needs to be defined is the relocation number for R_ARM_IRELATIVE. What's the best way of handling that? The main options seem to be:
Reserve a relocation number with ARM first (129?).
Go ahead and implement it without having the EABI updated. See whether the results are good before deciding whether to bless it in the EABI.
Since STT_GNU_IFUNC is a GNU-specific, treat R_ARM_IRELATIVE as GNU-specific too, and pinch one of the R_ARM_PRIVATE relocs.
I'm pretty sure (3)'s not the way to go, but I was aiming for completeness. :-)
The correct thing to do is to email arm.eabi@arm.com with a request for some numbers to be allocated to the relocations you require.
You email should contain: * The number of relocations desired; * Suggested names for the relocations; * Relocation types (static or dynamic); * A description of the intended use/behaviour of the relocations.
You will then be allocated the numbers.
However, if you need to start developing before numbers are assigned in the ABI you should use relocations in the private space: R_ARM_PRIVATE_<n> (number = 112+n, n=0...15).
These private relocations are guaranteed not to be assigned for other uses, and no released tool should be using them, so they are suitable for development purposes. However, by the time you come to release anything you need to use the numbers assigned by the ABI.
Thanks,
Matt