Re: clang/musl progress and a small bug.

[Rich Felker <dalias@aerifal.cx>]

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