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:06:57AM -0400, Daniel Jacobowitz wrote:
> On Thu, Aug 16, 2007 at 05:54:55AM -0700, H.J. Lu wrote:
> >   GNU_ATTR       0x008004 0x00000000 0x00000000 0x0002c 0x00000 RW  0x1
> > 
> >  Section to Segment mapping:
> >   Segment Sections...
> >    00     .text
> >    01     .ARM.attributes
> > [hjl@gnu-6 attr-1]$
> > 
> > Run-time loader can access the attribute section by checking offset
> > and filesize without making it SEC_ALLOC.
> 
> Because you now have a non-allocated section that you want the runtime
> loader to look at.  There's no guarantee that it is mapped in memory
> anywhere after mapping the PT_LOAD segments.  Forcing the runtime
> loader to make an extra mmap to get at the attributes basically
> ensures that glibc's loader won't do so - that's at least one extra
> syscall for every loaded object.

Not if the size of GNU_ATTR is 0.

> 
> 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. 

Assuming we want to make the attribute section SHF_ALLOC, what kind
of problem will it cause for ARM EABI?


H.J.


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