This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFC: Adding an extra field to Elf_Internal_Sym


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...

R.

> 
> Richard



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]