This is the mail archive of the 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 as well, else you will miss 
__stack_chk_guard/__stack_chk_fail (true for all libs as well)
The best way would be to set up the linker script for 
glibc internal links earlier so that everything automatically links 
against and use that everywhere 
instead of the hardcoded 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 (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

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