RFC: Adding an extra field to Elf_Internal_Sym

[Richard Sandiford]

Richard Earnshaw <rearnsha@arm.com> writes:
> On Tue, 2010-11-30 at 17:00 +0000, Richard Sandiford wrote:
>> Richard Earnshaw <rearnsha@arm.com> writes:
>> > 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.
>> 
>> OK, thanks.
>> 
>> > 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.
>> 
>> Do you mean keeping the T bit in the symbol value, rather than masking
>> it out?
>> 
>> I'd originally rejected that because it seemed to make things more
>> complicated.  I hadn't realised "nm" got things wrong though.  If we do
>> want things like "nm" to print the in-object symbol value, then maybe we
>> should go that way and add helper functions to mask out the T bit when
>> needed.
>
> No, I was thinking of moving it to a different field (attribute) rather
> than changing the type of the symbol (so all function symbols are then
> STT_FUNC).
>
> There certainly is an argument that nm should use the raw value field of
> a symbol, but I'm more concerned at present that we get output such as 
>
> sym                 |00000000|   T  |<processor specific>: 13|        |     |.text
>
> Which is misleading on ARM EABI as there is no such type...

Ah, yeah, hadn't thought of trying sysv mode.  That does seem a
convincing argument against making up a new internal-only symbol type
for Thumb STT_GNU_IFUNCs.  It looks like it is a choice between the new
Elf_Interanl_Sym field (which fixes the output above) and keeping the T
bit in the raw symbol value.

Does anyone have any feel for how disruptive it would be for users
if we make nm print odd values?

Richard