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: Map GNU attributes section to PT_GNU_ATTR (aka PT_GNU_STACK) segment


> > > > I don't think this patch is a good idea.  I would prefer to back it
> > > > out until there is a clear use case and support from at least one
> > > > consumer.
> > >
> > > I have got a request to mark a binary for a totally different ABI than
> > > the normal one. They wanted to use ELF header to mark the ABI. But the
> > > bits in ELF header are very limited. The attribute section is
> > > perfect for this.
> >
> > I stand by my request.  Please at least talk to Jakub about this
> > before you go changing program headers.
>
> Also, I see that ARM defined a separate ARM-specific program header
> for the sort of information you want; look for PT_ARM_ARCHEXT in
> http://www.arm.com/pdfs/aaelf.pdf.
>
> The contents are deliberately not in the same format as
> .ARM.attributes, because .ARM.attributes is not designed to be
> efficient to parse.  Also a lot of it - e.g. per-function and per-file
> attributes, which the GNU tools do not yet generate - is uninteresting
> to the loader.

I can confirm that the ARM EABI .ARM.attributes section is only intended for 
use by the static linker. I can't find anything in the docs, but the intent 
of the EABI committee was that it should not be an allocateable section.
It's way too big and complicated to be suitable for use at runtime.

Paul


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