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 Monday 03 April 2006 19:35, Peter S. Mazinger wrote:
> 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

Thanks, I'll look into all those things.
Something is definitely not working on my system as libc.a only has 
stack_chk_fail(_local), but gcc defines my glibc as having ssp.

nm /usr/lib/libc.a | grep stack_chk

00000000 T __stack_chk_fail
         U __stack_chk_fail
00000000 T __stack_chk_fail_local

Thanks for the new direction.

Hamish Greig

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