Re: RFC: Adding an extra field to Elf_Internal_Sym

[Richard Earnshaw <rearnsha at arm dot com>]

On Tue, 2010-11-30 at 10:16 +0000, Richard Sandiford wrote:
> Alan Modra <amodra@gmail.com> writes:
> > On Fri, Nov 26, 2010 at 11:44:27AM +0000, Richard Sandiford wrote:
> >> One option is to add an internal-only st_type.  There is one free:
> >> STT_LOPROC + 1.  But we'd then be scuppered if a real ARM-specific
> >> st_type was defined in future.
> >
> > You also have STT_LOOS+1 and STT_LOOS+2.  That gives you three to
> > choose from, and since this is internal only you can change between
> > those values at will.  I think that's the way I'd go.
> 
> Hmm, OK.  If we're prepared to use the OS range in that way,
> maybe we should use it from the outset, as a statement of intent.
> Would it be OK to start with STT_LOOS+2, say as:
> 
>    #define STT_GNU_INTERNAL 12
> 
> and then:
> 
>    #define STT_GNU_ARM_TIFUNC STT_GNU_INTERNAL
> 
> ?
> 
> ARM maintainers, do you have any preference between the two approaches
> (symbol type vs. on-the-side information)?  For reference, the original
> message was:
> 
>    http://sourceware.org/ml/binutils/2010-11/msg00475.html
> 
> Richard

I think your argument about the risk of externally exposing internal
data is persuasive.  Other than that, I have no objection to either
approach provided it doesn't change anything in the written object file.

I think there's perhaps also an argument for doing something along these
lines for the T bit in function symbols.  At present the use of
STT_THUMB_FUNC internally causes tools like nm to incorrectly list Thumb
function symbols.

R.