From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/772 Path: news.gmane.org!not-for-mail From: Szabolcs Nagy Newsgroups: gmane.linux.lib.musl.general Subject: Re: New gcc wrapper to try Date: Wed, 25 Apr 2012 01:53:39 +0200 Message-ID: <20120424235339.GV16237@port70.net> References: <20120421064933.GF14673@brightrain.aerifal.cx> <20120421203751.GG14673@brightrain.aerifal.cx> <20120422225704.75a67b0b@newbook> <20120423091905.GM14673@brightrain.aerifal.cx> <20120424122828.50cdc737@newbook> <20120424212840.GA13491@openwall.com> <20120424214127.GQ14673@brightrain.aerifal.cx> <20120424221040.GS14673@brightrain.aerifal.cx> <20120424221423.GA13817@openwall.com> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1335311635 23515 80.91.229.3 (24 Apr 2012 23:53:55 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 24 Apr 2012 23:53:55 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-773-gllmg-musl=m.gmane.org@lists.openwall.com Wed Apr 25 01:53:55 2012 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1SMpYO-0003jd-FR for gllmg-musl@plane.gmane.org; Wed, 25 Apr 2012 01:53:52 +0200 Original-Received: (qmail 9529 invoked by uid 550); 24 Apr 2012 23:53:52 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 9521 invoked from network); 24 Apr 2012 23:53:51 -0000 Content-Disposition: inline In-Reply-To: <20120424221423.GA13817@openwall.com> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:772 Archived-At: * Solar Designer [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