Re: Should we combine PT_GNU_STACK from DSO?

["H. J. Lu" <hjl at lucon dot org>]

On Fri, Apr 16, 2004 at 02:56:28PM -0400, Ian Lance Taylor wrote:
> "H. J. Lu" <hjl@lucon.org> writes:
> 
> > Currently, we have
> > 
> > [hjl@gnu-psc stack-2]$ make
> > gcc -g   -c -o foo.o foo.c
> > gcc -fPIC -shared -o libbar.so bar.c -Wl,-z,execstack
> > readelf -l libbar.so | grep STACK | grep RWE
> >   STACK          0x000000 0x00000000 0x00000000 0x00000 0x00000 RWE 0x4
> > gcc -o foo foo.o libbar.so -Wl,-rpath,.
> > ./foo
> > Hello
> > readelf -l foo | grep STACK
> >   STACK          0x000000 0x00000000 0x00000000 0x00000 0x00000 RW  0x4
> > readelf -l foo | grep STACK | grep RWE
> > make: *** [all] Error 1
> > 
> > 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.

> 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.


H.J.