Hi,
Just wondering if klibc are planning on supporting the .note.GNU-stack
section and all it entails ?
On sort of a related topic - we have QA tests that checks if something
have executable stack. Klibc of course fails due to the many .S, and
not passing --noexecstack to gas. Adding this to
EXTRA_KLIBC{C,A,LD}FLAGS fixes the issue for all the syscalls, crt0.o,
interp.o and the .so, as well as all the static linked binaries are also
fine. All shared binaries though have executable stack, even with
noexecstack passed to both gas and ld. Anybody know if the way klibc
shared binaries work needs executable stack ?
Thanks,
--
Martin Schlemmer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url :
http://www.zytor.com/pipermail/klibc/attachments/20060708/05fc6aed/attachment.bin
Martin Schlemmer wrote:> Hi, > > Just wondering if klibc are planning on supporting the .note.GNU-stack > section and all it entails ?I don't see any reason to.> On sort of a related topic - we have QA tests that checks if something > have executable stack. Klibc of course fails due to the many .S, and > not passing --noexecstack to gas. Adding this to > EXTRA_KLIBC{C,A,LD}FLAGS fixes the issue for all the syscalls, crt0.o, > interp.o and the .so, as well as all the static linked binaries are also > fine. All shared binaries though have executable stack, even with > noexecstack passed to both gas and ld. Anybody know if the way klibc > shared binaries work needs executable stack ?No, they don't. However, whenever you pass another option to gas, then you have to put the appropriate protection in place just in case an older toolchain -- or another architecture -- doesn't support it. -hpa