Re: PATCH: Map GNU attributes section to PT_GNU_ATTR (aka PT_GNU_STACK) segment

["H.J. Lu" <hjl at lucon dot org>]

On Thu, Aug 16, 2007 at 03:00:40PM -0400, Daniel Jacobowitz wrote:
> On Thu, Aug 16, 2007 at 10:11:05AM -0400, Daniel Jacobowitz wrote:
> > On Thu, Aug 16, 2007 at 06:53:58AM -0700, H.J. Lu wrote:
> > > On Thu, Aug 16, 2007 at 09:43:10AM -0400, Daniel Jacobowitz wrote:
> > > > 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.

For the attribute info in executable and shared library, there
should be no difference between linker and loader. Do we need
the full content of .ARM.attributes section in executable and shared
library? It sounds to me that PT_ARM_ARCHEXT can just have a
.ARM.attributes section which can be generated from .ARM.attributes
in input relocatable files.  .ARM.attributes in executable and shared
library can smaller and different from .ARM.attributes in relocatable
files. Readelf will check PT_ARM_ARCHEXT to see how .ARM.attributes
should be processed.


H.J.