[PATCH RFC] gas/ELF: don't accumulate .type settings

Nick Clifton nickc@redhat.com
Tue Jul 2 09:59:00 GMT 2019

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

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.


More information about the Binutils mailing list