Re: New gcc wrapper to try

[Szabolcs Nagy <nsz@port70.net>]

* Solar Designer <solar@openwall.com> [2012-04-25 02:14:23 +0400]:
> On Tue, Apr 24, 2012 at 06:10:40PM -0400, Rich Felker wrote:
> > On Tue, Apr 24, 2012 at 05:41:27PM -0400, Rich Felker wrote:
> > > The problem is that the default gcc build incorporates glibc ABI
> > > knowledge (layout of the thread structure) and the assumption that the
> > > thread pointer has been initialized into any binary built with stack
> > > protector. Just adding symbols will not fix anything.
> 
> I did not realize that.
> 
> > ......but since you requested it, I'm working on trying to make it
> > work anyway. We'll see how it goes. Preliminary support was just
> > committed.
> 
> Wow.  At this time, I suggested it as being good for the musl project
> rather than requested it for my own use (although I imagine that I might
> want to use it at some point), but this does not make me any less
> impressed by your work on it.
> 

btw i noticed that with the modified gcc where
-fstack-protector is enabled by default, the
stricter -fstack-protector-all does not work
(at least here with gcc 4.4.3)

the workaround is to turn it off and on again:
-fno-stack-protector -fstack-protector-all
works

this might be good to know when someone tries to
catch stack corruption issues


actually it would be quite useful if the compiler
could emit proper bounds check for stack access

address-sanitizer does something like that
https://code.google.com/p/address-sanitizer/

stack corruption bugs can be annoying to debug
without such a tool