RFC: Map GNU attributes section to PT_GNU_STACK segment

[Mike Frysinger]

On Thursday 16 August 2007, Mike Frysinger wrote:
> On Wednesday 15 August 2007, H.J. Lu wrote:
> > On Wed, Aug 15, 2007 at 05:07:37PM +0100, Nick Clifton wrote:
> > > Hi H.J.
> > >
> > > >We keep GNU attributes section in executable and shared library. Also
> > > >There is a PT_GNU_STACK segment. But only its segment type is used.
> > > >This patch maps GNU attributes section to PT_GNU_STACK segment and
> > > >makes PT_GNU_ATTRIBUTES an alias of PT_GNU_STACK so that GNU
> > > > attributes section is available to ELF loader.
> > >
> > > Why do you want to do this ?  In particular why do you want to overload
> > > the PT_GNU_STACK segment ?  Why not create a new PT_GNU_ATTR segment ?
> > > Is space in the header the only reason ?
> > >
> > > It seems to me that overloading the PT_GNU_STACK segment in the way you
> > > propose is prone to confusing the user, and I think that we ought to
> > > try to avoid this.
> >
> > The current usage of the PT_GNU_STACK segment is the flags field
> > only.  All other fields are ignored.  The new segment ignores the
> > flags field.  Overloading the PT_GNU_STACK segment seems a good
> > idea to me since it is totally backward and forward compatible.
>
> this is not correct ... on Blackfin, we use the other attributes of
> PT_GNU_STACK (like the memsize field) to control the stack size (since
> Blackfin is a no-mmu)

to be a little more precise ... all Linux ports which support FDPIC ELF 
utilize the memsize field to set the stack size of the application, so this 
isnt Blackfin-specific
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 827 bytes
Desc: This is a digitally signed message part.
URL: <https://sourceware.org/pipermail/binutils/attachments/20070816/4cf4684d/attachment-0001.sig>