[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120424235339.GV16237@port70.net>
Date: Wed, 25 Apr 2012 01:53:39 +0200
From: Szabolcs Nagy <nsz@...t70.net>
To: musl@...ts.openwall.com
Subject: Re: New gcc wrapper to try
* Solar Designer <solar@...nwall.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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
