glibc-2.4 __stack_chk_guard/__pointer_chk_guard
Hamish Greig
hgreig@bigpond.net.au
Mon Apr 3 00:44:00 GMT 2006
On Tuesday 07 March 2006 20:47, Roland McGrath wrote:
> There is indeed no present problem. The linker behavior does the right
> thing implicitly. That right thing is a potential gotcha for accidental
> changes in the future. i.e., if you do introduce the symbol in the future
> on some configuration, then you need to make sure that it gets into a newer
> version set so that configuration's ABI version dependencies work right.
> But uglifying the sources further to avoid the symbol appearing in the
> version script is no less error-prone. Instead, we rely on checking the
> resultant dynamic symbol lists to watch out for such stray symbols.
Building glibc-2.4 with gcc-4.1 I found two things that I thought might be
related to this. Apologies if I am mistaken.
gcc-4.1 checks if glibc supports ssp and if yes, doesn't add -lssp* to the
fstack-protector specs. So nscd fails to build when gcc has been built
against glibc2.4, unless I add -lssp to the nscd Makefile rules or manually
change the gcc's specs.
The second thing I noticed is when I specify -disable-ssp in gcc's configure
nothing on my system exports __stack_ghk_guard (normally in libssp and
libssp_nonshared), and compiling nscd fails unless I force the
stack-protector check in glibc's configure (libc_cv_ssp) to fail.
I have got to this point and without being a programmer I am stuck where to go
from here, whether glibc's __stack_chk_fail and gcc's __stack_chk_guard are
different implementations of the same thing or if I need to file a bug (for
glibc or gcc or both) or fix/ adjust my build system.
I am very happy to give more information about my system and the build if
wanted.
Hamish Greig
More information about the Libc-alpha
mailing list