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


On Thu, Aug 16, 2007 at 09:43:10AM -0400, Daniel Jacobowitz wrote:
> On Thu, Aug 16, 2007 at 06:20:50AM -0700, H.J. Lu wrote:
> > Not if the size of GNU_ATTR is 0.
> 
> It is unlikely to be in the future.  I expect we will use this
> mechanism for many platforms.  We already do on ARM, MIPS, and Power.
> 
> > > How are you planning to use this in the loader, and have you discussed
> > > it with the glibc maintainers at all?
> > 
> > My patch only makes the existing info available to run-time loader.
> > It is up to run-time loader to decide if it wants to look at it.
> > At the moment, I don't have an attribute the run-time loader has
> > to check. But things may change in the future. 
> 
> If the run time loader wants to check, your mechanism will not be
> suitable.  There's no chance that glibc will do an extra mmap or
> seek/read to get at this information.
> 
> 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.

> 
> > Assuming we want to make the attribute section SHF_ALLOC, what kind
> > of problem will it cause for ARM EABI?
> 
> Apparently none; the EABI does not specify that the section is
> non-ALLOC.
> 

Then, can we make the attribute section SHF_ALLOC?


H.J.


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