This is the mail archive of the
mailing list for the glibc project.
Re: glibc-2.4 __stack_chk_guard/__pointer_chk_guard
- From: "Peter S. Mazinger" <ps dot m at gmx dot net>
- To: Hamish Greig <hgreig at bigpond dot net dot au>
- Cc: libc-alpha at sourceware dot org, Roland McGrath <roland at redhat dot com>, Jakub Jelinek <jakub at redhat dot com>
- Date: Mon, 3 Apr 2006 11:35:21 +0200 (CEST)
- Subject: Re: glibc-2.4 __stack_chk_guard/__pointer_chk_guard
On Mon, 3 Apr 2006, Hamish Greig wrote:
> 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.
You shouldn't need -lssp, if glibc has ssp support builtin, the trouble in
the whole glibc tree is that it needs to link against
libc_nonshared.a and ld-linux.so.2 as well, else you will miss
__stack_chk_guard/__stack_chk_fail (true for all non-libc.so libs as well)
The best way would be to set up the libc.so linker script for
glibc internal links earlier so that everything automatically links
against libc.so.6/libc_nonshared.a/ld-linux.so.2 and use that everywhere
instead of the hardcoded libc.so.6 only.
> 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.
__stack_chk_guard can also come from glibc's ld-linux.so.2 (but only if
TLS is not supported on your arch) or libc.a.
> 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.
they are different, __stack_chk_guard is the guard/canary itself,
__stack_chk_fail is the function that reports it.
Peter S. Mazinger <ps dot m at gmx dot net> ID: 0xA5F059F2
Key fingerprint = 92A4 31E1 56BC 3D5A 2D08 BB6E C389 975E A5F0 59F2