This is the mail archive of the
mailing list for the binutils project.
Re: [PATCH RFC] gas/ELF: don't accumulate .type settings
- From: Nick Clifton <nickc at redhat dot com>
- To: Jan Beulich <JBeulich at suse dot com>, "binutils at sourceware dot org" <binutils at sourceware dot org>
- Cc: "andrew dot cooper3 at citrix dot com" <andrew dot cooper3 at citrix dot com>
- Date: Tue, 2 Jul 2019 10:59:18 +0100
- Subject: Re: [PATCH RFC] gas/ELF: don't accumulate .type settings
- References: <email@example.com> <firstname.lastname@example.org> <email@example.com>
>> 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.