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:
1. Reserve a relocation number with ARM first (129?).
2. 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.
3. 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. :-)
Richard
On Wed, Nov 17, 2010, Richard Sandiford wrote:
- 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.
My understanding is that we need to have an implementation to be in a position to request inclusion; it's a bit chicken and egg, so we could just inform them that we're starting a prototype with this and that number and then circle back when it's done?
Loïc Minier loic.minier@linaro.org writes:
On Wed, Nov 17, 2010, Richard Sandiford wrote:
- 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.
My understanding is that we need to have an implementation to be in a position to request inclusion; it's a bit chicken and egg, so we could just inform them that we're starting a prototype with this and that number and then circle back when it's done?
Yeah, makes sense. I'll prototype it using one of the private relocs, but make sure that nothing gets committed into stable sources with that number.
Richard
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
linaro-toolchain@lists.linaro.org
-
Loïc Minier -
Matthew Gretton-Dann -
Richard Sandiford