[lld] r254003 - Revert "ELF: Make .note.GNU-stack more compatible with traditional linkers."

[Rui Ueyama via llvm-commits]

On Tue, Nov 24, 2015 at 2:51 PM, Joerg Sonnenberger via llvm-commits <
llvm-commits at lists.llvm.org> wrote:

> On Tue, Nov 24, 2015 at 02:42:48PM -0800, Rui Ueyama wrote:
> > On Tue, Nov 24, 2015 at 2:37 PM, Joerg Sonnenberger via llvm-commits <
> > llvm-commits at lists.llvm.org> wrote:
> >
> > > On Tue, Nov 24, 2015 at 02:23:34PM -0800, Rui Ueyama wrote:
> > > > Omitting PT_GNU_STACK when -z execstack is provided is easy, but it
> leads
> > > > to a counter-intuitive behavior on platforms that do not recognize
> > > > PT_GNU_STACK and stack is not executable by default. (You need to
> pass -z
> > > > execstack to make it run on such platforms, but it wouldn't make the
> > > stack
> > > > executable.)
> > >
> > > That argument makes no sense to me and I am not even sure I understand
> > > it correctly. A platform (like NetBSD) that doesn't recognize
> > > PT_GNU_STACK and provides a non-executable stack by default will not be
> > > affected at all. Yes, it won't do what is intended, but it is no worse
> > > than the current situation of creating a bogus program header either.
> > >
> >
> > Let me rephrase. That you needs to pass "-z execstack" (although you
> don't
> > intend to make the stack executable) to make the output compatible with a
> > platform that rejects executables with PT_GNU_STACK is I think
> > counter-intuitive.
>
> I agree that it is counter-intuive from the option name, but not if you
> consider the header entry as a way to only flag binaries with
> non-default non-execstack. A better name would be -z noexecstackheader,
> but the question really just is that *some* form should be supported.
> Not emiting the header if it doesn't do anything sounds perfectly
> reasonable to me, it wastes less space and allows producing binaries
> fully matching the original ELF specification.
>

OK, I can omit PT_GNU_STACK segment if -z execstack is provided. It is
simple enough and also provides a way to remove the segment. Does this
sound good?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20151124/0d2bc9d3/attachment.html>