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 Nick,

On 01.07.2019 14:48, Nick Clifton wrote:
>> Make the behavior predictable:
> 
> I think that this would be a great idea.
> 
>> Is a diagnostic needed (perhaps unless changing to @notype)?
> 
> Yes.  If the type changes are significant then the user should
> be informed.  I also like the idea of not warning on changes to
> @notype.  Presumably this is to allow a deliberate change of
> type to happen.

Yes.

>  We should document this feature however.

Will do.

>> What to do with @common? It getting set involves more than just setting
>> STT_OBJECT. Should type changes on common symbols be disallowed?
> 
> Hmm, I am kind of leaning towards allowing changes from common to
> something else, but not the other way around.  (Assuming that the
> new object is at least the same size as the common object).  But
> given what you have said, and having a look at the code myself, I
> agree that it might be safer just to disallow any changes involving
> common symbols.
> 
> 
>> Is anyone aware of any other caveats here?
> 
> 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 ...

Jan

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