This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: Should we combine PT_GNU_STACK from DSO?
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.