From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/913 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: clang/musl progress and a small bug. Date: Fri, 25 May 2012 19:17:27 -0400 Message-ID: <20120525231727.GA163@brightrain.aerifal.cx> References: <4797553.4BPKurOpfG@main.pennware.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 1337988160 6481 80.91.229.3 (25 May 2012 23:22:40 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 25 May 2012 23:22:40 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-914-gllmg-musl=m.gmane.org@lists.openwall.com Sat May 26 01:22:39 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 1SY3q7-0003rH-9K for gllmg-musl@plane.gmane.org; Sat, 26 May 2012 01:22:35 +0200 Original-Received: (qmail 20220 invoked by uid 550); 25 May 2012 23:22:35 -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 20212 invoked from network); 25 May 2012 23:22:34 -0000 Content-Disposition: inline In-Reply-To: <4797553.4BPKurOpfG@main.pennware.com> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:913 Archived-At: On Fri, May 25, 2012 at 04:40:51PM -0500, Richard Pennington wrote: > Hi, > > clang's libcompiler-rt doesn't have support for crtbegin.o and crtend.o so > global constructors and destructors didn't work out of the box. If I link with > the NetBSD versions of crtbegin.c and crtend.c in place of the musl crti.s and > crtn.s everything works fine. For now, I've added them to the musl build under > crt. These files are provided by gcc, not by the libc. I'm not very familiar with how they work, so I'm not sure what's best to do... I'll try to figure them out better. > I think I found a bug while running my library regression test. The zero test > failed in the following code: > > TEST_TRACE(C99 7.20.3.1) > p = calloc(100, sizeof(char)); > TEST(p != NULL, "calloc() returned a pointer"); > int flag = 1; > for (i = 0; i < 100; ++i) { > if (p[i] != 0) { > flag = 0; > } > } > TEST(flag, "calloc() returned zeroed memory"); > > The TEST() macro is kind of like assert but it prints out the message and > counts failures and successes: > > PASS: 001stdlib.c:74: Stdlib(Stdlib): calloc() returned a pointer > FAIL: 001stdlib.c:81: Stdlib(Stdlib): calloc() returned zeroed memory > Stdlib unit tests completed > 32 tests run > 1 test failed > > Am I missing something? I'm guessing clang miscompiled calloc.c due to not respecting -ffreestanding. There was a related issue reported a while back by someone experimenting with clang and musl but I don't know what came of it. Basically I think the issue is that clang is treating the malloc call calloc makes as a call to the standard malloc, and optimizing out inspections calloc makes on the returned memory because it's "indeterminate" and thus undefined behavior. This contradicts the meaning of -ffreestanding which is to behave as a freestanding C environment where malloc and other library functions are not special. I'm not sure how to work around the issue without making the code behave a lot worse. If you can determine this is the issue, I think it really calls for a bug report to clang... Rich