Should we combine PT_GNU_STACK from DSO?
Ian Lance Taylor
ian@wasabisystems.com
Fri Apr 16 20:06:00 GMT 2004
"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
More information about the Binutils
mailing list