From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/3798 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Solving the recursive memcpy/memset/etc. issue Date: Thu, 1 Aug 2013 13:48:04 -0400 Message-ID: <20130801174804.GL221@brightrain.aerifal.cx> References: <20130801004940.GA20323@brightrain.aerifal.cx> <51F9FA8D.2000403@gentoo.org> <20130801062007.GI221@brightrain.aerifal.cx> <51FA1651.1070801@gentoo.org> <1375345615.27318.228.camel@eris.loria.fr> 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 1375379302 24034 80.91.229.3 (1 Aug 2013 17:48:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 1 Aug 2013 17:48:22 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-3802-gllmg-musl=m.gmane.org@lists.openwall.com Thu Aug 01 19:48:21 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 1V4wz5-00062l-Kb for gllmg-musl@plane.gmane.org; Thu, 01 Aug 2013 19:48:19 +0200 Original-Received: (qmail 13979 invoked by uid 550); 1 Aug 2013 17:48:18 -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 13971 invoked from network); 1 Aug 2013 17:48:18 -0000 Content-Disposition: inline In-Reply-To: <1375345615.27318.228.camel@eris.loria.fr> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:3798 Archived-At: On Thu, Aug 01, 2013 at 10:26:55AM +0200, Jens Gustedt wrote: > Am Donnerstag, den 01.08.2013, 10:03 +0200 schrieb Luca Barbato: > > > Well, it would be an ugly heuristic like running cc -S -o - on > > > src/string/memcpy.c, with -Dmemcpy=noname or something, and grepping > > > the output for memcpy... > > > > Indeed. > > there might be the word memcpy in comments or whatever, depends on the > assembler format etc. might be really relatively difficult to set up > reliably. Well as long as they're false-positives for detecting the bug rather than false-negatives, at worst you'd get a slow memcpy rather than a crashing libc. > - compile it with that -Dmemcpy=noname trick to a normal .o and use > nm to look for an undefined symbol "memcpy". Using nm is undesirable with respect to cross-compiling. It requires detecting the right version of nm to run, which may be hard; I don't even have *-linux-musl-nm in my path on my laptop here, just the gcc. Right now cross-compiling is as simple as setting CC to the cross compiler, and I don't want to break that. > - use a different name for the implementation of the function from > the start, __musl_memcpy or so. Then you could do the check for the > memcpy symbol on the normally compiled .o and (if everything is ok) > rename the __musl_memcpy to memcpy with some linker trick. This is a lot more ugliness in the build system and I'm not clear on the benefit over the above methods. > - put "#define memcpy __musl_memcpy" at the start of string.h > if __musl_memcpy would refer to memcpy this would give an link time > error for an undefined symbol. No linking is done to make libc.a. As for linking applications, the symbol memcpy must exist. You are always permitted to remove macro definitions and refer to the underlying function. Even if this were valid, it would change the ABI in a very ugly hackish way that belongs in glibc, not musl. Rich