RFC: Map GNU attributes section to PT_GNU_STACK segment

H.J. Lu hjl@lucon.org
Wed Aug 15 16:19:00 GMT 2007


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.

> 
> On the other hand, if you are trying to tidy up the program headers then 
> maybe it would be cleaner to have a new name (eg PT_GNU_STUFF) and then 
> define an *extendable* scheme for putting loader-accessible information 
> into this segment.  Using this scheme you can then define a replacement for 
> the current PT_GNU_STACK segment and a home for the GNU attributes section. 
> Ideally this new segment would be backwards compatible with the current 
> PT_GNU_STACK segment (same type, same flags) so that older loaders can 
> still use it.

That is what my proposal does. The only difference is I call the
new segment PT_GNU_ATTRIBUTES.  I don't mind we use a differrent
name at all.  The loader-accessible information belongs to the GNU
attributes section and it is extendable.


H.J.



More information about the Binutils mailing list