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: [PATCH RFC] gas/ELF: don't accumulate .type settings


Hi Jan,

>> No - but one thing I have wanted to add to the assembler for some
>> time now is the ability to set the type to an arbitrary value.
>> Possibly restricted to the range of STT_LOOS .. STT_HIPROC.  I have
>> tried a couple of times, but could not find a clean solution.  I am
>> mentioning it now just as a suggestion that maybe the masking code
>> you are adding should skip symbols with target specific semantics.
> 
> Hmm, and how would I recognize "target specific semantics" in
> obj_elf_type()? I'm afraid I'm not familiar enough with the BFD
> internals ...

Well yes, that is the problem.  There is no direct 1:1 mapping between 
ELF symbol types and bfd symbol flags, which is why I have been having
problems adding the new types.

I think that the best solution here would be to include a new assembler
backend function, eg "md_elf_symbol_type_change(old,new)", which backends
could define if they need to determine for themselves whether a type
change is OK.  If the function is defined and returns say "TRUE", then
your new code would not complain about the type change, otherwise it
would carry on and perform its other checks before issuing a warning
message.

By default of course the macro would be undefined, but if it turns out
later on that certain targets use special symbol types then they can
define the macro and do what they need to do.

Cheers
  Nick





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