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