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.