Re: Should we combine PT_GNU_STACK from DSO?

[Ian Lance Taylor <ian at wasabisystems dot com>]

"H. J. Lu" <hjl@lucon.org> writes:

> > > That is we don't combine PT_GNU_STACK from DSO. This executable may
> > > fail to run on kernel with non-executable stack. But we can also argue
> > > that the DSO used at run-time may not need an executable stack. Any
> > > comments?
> > 
> > It seems to me that the dynamic linker has to be responsible for this.
> 
> It doesn't work:
> 
> http://www.uwsg.iu.edu/hypermail/linux/kernel/0404.2/0141.html
> 
> since the Linux kernel with non-executable stack won't allow it.

Well, I suppose I do understand that point.  I guess that I agree that
the binutils linker should migrate a writable PT_GNU_STACK from any
explicitly named shared library into the executable.

I'll add my general comment that I dislike this whole scheme anyhow.

> > Otherwise we will fail if the shared library is updated and
> > PT_GNU_STACK changes.  I see no reason for the binutils linker to
> > handle it.
> > 
> > Note that the scheme falls apart when using dlopen in any case.
> > 
> 
> I know. See above. I can see the points from both linker and kernel.
> The current scheme doesn't work too well. I am looking for a compromise
> which is acceptable to everyone.

A program which expects to dlopen a writable PT_GNU_STACK shared
library will have to use the mysterious undocumented linker option.
Good luck finding it.

A shared library which changes from non-writable PT_GNU_STACK to
writable PT_GNU_STACK will break all existing users with no good
workaround at all.

Ian