From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/3790 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Solving the recursive memcpy/memset/etc. issue Date: Wed, 31 Jul 2013 20:49:40 -0400 Message-ID: <20130801004940.GA20323@brightrain.aerifal.cx> 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: ger.gmane.org 1375318190 17201 80.91.229.3 (1 Aug 2013 00:49:50 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 1 Aug 2013 00:49:50 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-3794-gllmg-musl=m.gmane.org@lists.openwall.com Thu Aug 01 02:49:53 2013 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 1V4h5V-0002kp-2n for gllmg-musl@plane.gmane.org; Thu, 01 Aug 2013 02:49:53 +0200 Original-Received: (qmail 28366 invoked by uid 550); 1 Aug 2013 00:49: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 28358 invoked from network); 1 Aug 2013 00:49:52 -0000 Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:3790 Archived-At: OK, so now that it's hit us for real, what should we do about GCC generating code for memcpy, memset, etc. which might contain infinite recursion? Aside from the ARM issue (which was separate), we know the option causing this bad code generation, and it can be disabled via -fno-tree-loop-distribute-patterns. However, if GCC policy is that they consider the compiler entitled to generate calls to memcpy/memset/memmove/memcmp whenever it wants, then we're just going to be playing whack-a-mole. The only fully viable option I see is replacing the code for these functions with code that uses volatile objects so as to make optimization utterly impossible. This will of course make them incredibly slow, but at least we would have safe, working C code, and we could add asm for each supported arch. An alternative might be to test the compiler in configure to determine if, with the selected CFLAGS, it generates recursive code for these functions, and if so, defining a macro that causes musl to revert to the volatile code. Other ideas? For now, if -fno-tree-loop-distribute-patterns fixes it (still waiting on confirmation for this) I'm going to commit that to configure, but it doesn't seem like a viable long-term solution. My ideal outcome would be a promise from the GCC developers that, in future GCC versions, -ffreestanding implies disabling any options which would generate calls to the mem* functions. However that sounds unlikely. Rich