This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

-- 
Peter S. Mazinger <ps dot m at gmx dot net>           ID: 0xA5F059F2
Key fingerprint = 92A4 31E1 56BC 3D5A 2D08  BB6E C389 975E A5F0 59F2


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]