clang/musl progress and a small bug.

clang/musl progress and a small bug.

[Richard Pennington]

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.

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?

-Rich

Re: clang/musl progress and a small bug.

[Rich Felker]

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

Re: clang/musl progress and a small bug.

[aep]

On Fri, 25 May 2012 16:40:51 -0500, Richard Pennington wrote:

> 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.

Are you sure that you actually need them, and that those aren't just 
the names of the gcc specific version of it?
Not having global dtors in libcompiler-rt at all, sounds kinda broken. 
Last time i tried, i think musl was just missing some hooks in that 
area.
However, i mixed in clangs C++ lib, so maybe this works different.

Re: clang/musl progress and a small bug.

[John Spencer]

On 05/26/2012 01:17 AM, Rich Felker wrote:
> On Fri, May 25, 2012 at 04:40:51PM -0500, Richard Pennington wrote:
>
>> 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
>
has this issue been reported on the LLVM list finally ?
imo this is a major blocker