build musl with clang

build musl with clang

[agent]

i am trying to build musl with clang 3.0 from ubuntu 12.04. musl itself 
builds fairly fine with some notes on unused command line parameters and 
coding style. but i have some issues compiling a simple hello world 
program against this musl. the code is:

#include <stdio.h>

int main(int argc, char **argv) {
     printf("Hello, World!\n");
     return 0;
}

i have tried to link against musl both dynamically and statically. if i 
compile a program with the default ld-linux.so dynamic linker the 
program runs but fails at the end:

Hello, World!
Inconsistency detected by ld.so: dl-fini.c: 207: _dl_fini: Assertion `ns 
!= 0 || i == nloaded' failed!

if i use musl's ld-musl (as far as i can notice it is just symlink to 
libc.so) i get a segfault. gdb says:

(gdb) r
Starting program: /home/agent/dev/musl/musl-0.9.4_clang/lib/t.out

Program received signal SIGSEGV, Segmentation fault.
0xb7f9d73a in find_sym () from /lib/ld-musl-i386.so.1
(gdb) where
#0  0xb7f9d73a in find_sym () from /lib/ld-musl-i386.so.1

btw, exactly the same things happen when i try it with gcc (4.6.3 from 
ubuntu).

if i compile statically with gcc the program works fine, but with clang 
it even does not compile (i mean link):

/opt/musl-clang/lib/libc.a(vfprintf.o): In function `printf_core':
src/stdio/vfprintf.c:(.text+0x1088): undefined reference to `__udivdi3'
src/stdio/vfprintf.c:(.text+0x10a6): undefined reference to `__umoddi3'
/opt/musl-clang/lib/libc.a(vfprintf.o): In function `fmt_u':
src/stdio/vfprintf.c:(.text+0x1a11): undefined reference to `__udivdi3'
src/stdio/vfprintf.c:(.text+0x1a33): undefined reference to `__umoddi3'
clang: error: linker command failed with exit code 1 (use -v to see 
invocation)

i suppose those functions do not get into libc.a for some reason, but 
they are in libc.so according to readelf.

my clang command lines:
dynamic link:

clang -Wall -nostdlib -nostdinc -Wl,-dynamic-linker 
/lib/ld-musl-i386.so.1 -L/opt/musl-clang/lib -isystem 
/opt/musl-clang/include/ /opt/musl-clang/lib/crt1.o 
/opt/musl-clang/lib/crti.o t.c /opt/musl-clang/lib/crtn.o -o t.out -lc

static link:
clang -Wall -nostdlib -nostdinc -L/opt/musl-clang/lib -isystem 
/opt/musl-clang/include/ /opt/musl-clang/lib/crt1.o 
/opt/musl-clang/lib/crti.o t.c /opt/musl-clang/lib/crtn.o -o t.out 
-static -lc

as far as i can see, musl do not provide crtbegin.o and crtend.o, clang 
do not have it's own and if i add gcc's ones situation does not change.

maybe i am wrong with clang parameters (i based them on gcc spec 
provided), maybe it is impossible to compile a working musl with clang 
at this stage, maybe a quick fix can be applied (:

PS: sorry for so long message -- i'd like to be maximum verbose
PPS: and sorry for duplicates if any -- i didn't find any search on 
mainling list archive

Re: build musl with clang

[Szabolcs Nagy]

* agent <agentprog@gmail.com> [2012-08-23 13:53:18 +0600]:
> i am trying to build musl with clang 3.0 from ubuntu 12.04. musl
> itself builds fairly fine with some notes on unused command line

i've never tried to build musl with clang
but others did so it should work

in config.mak setup LIBCC properly
(it defaults to -lgcc in the Makefile, this is needed for
udiv* symbols provided by the compiler on 32bit archs for
64bit int division)

i recommend using -g in the cflags and ldflags
so you have debug symbols

don't use the system ld.so

> my clang command lines:
> dynamic link:
> 
> clang -Wall -nostdlib -nostdinc -Wl,-dynamic-linker
> /lib/ld-musl-i386.so.1 -L/opt/musl-clang/lib -isystem
> /opt/musl-clang/include/ /opt/musl-clang/lib/crt1.o
> /opt/musl-clang/lib/crti.o t.c /opt/musl-clang/lib/crtn.o -o t.out
> -lc
> 
> static link:
> clang -Wall -nostdlib -nostdinc -L/opt/musl-clang/lib -isystem
> /opt/musl-clang/include/ /opt/musl-clang/lib/crt1.o
> /opt/musl-clang/lib/crti.o t.c /opt/musl-clang/lib/crtn.o -o t.out
> -static -lc
> 

you need the LIBCC here as well, otherwise it looks ok

maybe try to link separately with ld
(clang might invoke ld in hideous ways)

# if there is no crtbegin.o,crtend.o then remove them
START="$MUSL/lib/crti.o $MUSL/lib/crt1.o $CLANG/lib/crtbegin.o"
END="$CLANG/lib/crtend.o $MUSL/lib/crtn.o -L$MUSL/lib -lc -L$CLANG/lib -lclang"

# compile:
clang -c t.c -nostdinc -isystem $MUSL/include

# link: either one of the following should work
clang -nostdlib -Wl,-dynamic-linker,/lib/ld-musl-i386.so.1 $START t.o $END
ld -X -d -e _start -dynamic-linker /lib/ld-musl-i386.so.1 $START t.o $END

Re: build musl with clang

[agent]

23.08.2012 15:23, Szabolcs Nagy пишет:
>
>
> maybe try to link separately with ld
> (clang might invoke ld in hideous ways)
>
> # if there is no crtbegin.o,crtend.o then remove them
> START="$MUSL/lib/crti.o $MUSL/lib/crt1.o $CLANG/lib/crtbegin.o"
> END="$CLANG/lib/crtend.o $MUSL/lib/crtn.o -L$MUSL/lib -lc -L$CLANG/lib -lclang"
>
> # compile:
> clang -c t.c -nostdinc -isystem $MUSL/include
>
> # link: either one of the following should work
> clang -nostdlib -Wl,-dynamic-linker,/lib/ld-musl-i386.so.1 $START t.o $END
> ld -X -d -e _start -dynamic-linker /lib/ld-musl-i386.so.1 $START t.o $END
>
the way clang invokes ld is really weird because neither -dynamic-linker 
nor -Wl,-dynamic-linker override the option clang invokes ld, it is only 
appended to a command line. using ld explicitly works perfectly even 
without need for libclang when linking dynamically, at least for hello 
world. unfortunatelly ubuntu does not provide libclang.a in packages and 
i don't want to recompile clang itself, so i can't test static build 
right now, but it is good that at least dynamic linking works.

thanks for your help!

Re: build musl with clang

[Rich Felker]

On Thu, Aug 23, 2012 at 01:53:18PM +0600, agent wrote:
> i am trying to build musl with clang 3.0 from ubuntu 12.04. musl
> itself builds fairly fine with some notes on unused command line
> parameters and coding style. but i have some issues compiling a
> simple hello world program against this musl. the code is:
> 
> #include <stdio.h>
> 
> int main(int argc, char **argv) {
>     printf("Hello, World!\n");
>     return 0;
> }
> 
> i have tried to link against musl both dynamically and statically.
> if i compile a program with the default ld-linux.so dynamic linker
> the program runs but fails at the end:

This usage is not intended to work. At present it might be possible to
make it work for programs that don't use dlopen or TLS (which isn't
supported yet anyway), but in the long term I think using the GNU
dynamic linker is going to get more and more unrealistic, so it's
probably best not to even try.

> (gdb) r
> Starting program: /home/agent/dev/musl/musl-0.9.4_clang/lib/t.out
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0xb7f9d73a in find_sym () from /lib/ld-musl-i386.so.1
> (gdb) where
> #0  0xb7f9d73a in find_sym () from /lib/ld-musl-i386.so.1

Did you change the options musl was compiled/linked with? Naively, my
first guess is that -Bsymbolic-functions was omitted.

Rich

Re: build musl with clang

[agent]

23.08.2012 18:24, Rich Felker пишет:
> but in the long term I think using the GNU dynamic linker is going to 
> get more and more unrealistic, so it's probably best not to even try. 
i didn't want to, at first i missed -dynamic-linker option and it was 
the only somehow working variant.
> Did you change the options musl was compiled/linked with? Naively, my
> first guess is that -Bsymbolic-functions was omitted.
i was using

CC=clang ./configure --prefix=...

and other things were default. no changes to any files.

23.08.2012 18:24, John Spencer пишет:
> this sounds as if the binary uses gnu hash as opposed to sysv hash. 
> did you use ./configure ?
> see FAQ in http://wiki.musl-libc.org
i didn't use any build systems, just a shell script with commands. that 
was just a hello world. i was able to compile it and if i encounter any 
problems in future, i'll try the solution from FAQ.
btw, there was no link to this wiki from main site
> there is another known bug in clang which will lead to calloc getting 
> wrongly optimized away, because clang disrespects -ffree-standing. 
> Richard Pennington wanted to reported this to the LLVM maillist months 
> ago, but afaik he still hasn't done this.
i was investigating the possibility of using clang + musl for writing a 
new program, not for porting existing software, so it may be possible to 
avoid using some functions in reasonable scale, or change any component 
in this bundle.
and does that bug affect a whole *alloc family or just calloc?

Re: build musl with clang

[John Spencer]

On 08/23/2012 03:11 PM, agent wrote:
> 23.08.2012 18:24, John Spencer пишет:
>> this sounds as if the binary uses gnu hash as opposed to sysv hash. 
>> did you use ./configure ?
>> see FAQ in http://wiki.musl-libc.org
> i didn't use any build systems, just a shell script with commands. 
> that was just a hello world. 
i was referring to how you have built musl; musl's configure script 
detects broken distro toolchains and adds flags so that musl and 
musl-gcc is built with sysv hash only.

> i was able to compile it and if i encounter any problems in future, 
> i'll try the solution from FAQ.
> btw, there was no link to this wiki from main site

yes, for some reason rich didn't place a link there yet.

>> there is another known bug in clang which will lead to calloc getting 
>> wrongly optimized away, because clang disrespects -ffree-standing. 
>> Richard Pennington wanted to reported this to the LLVM maillist 
>> months ago, but afaik he still hasn't done this.
> i was investigating the possibility of using clang + musl for writing 
> a new program, not for porting existing software, so it may be 
> possible to avoid using some functions in reasonable scale, or change 
> any component in this bundle.
> and does that bug affect a whole *alloc family or just calloc?
>
the bug affects optimizations that assume things about libc functions, 
-ffree-standing is meant to turn them off but apparently this feature is 
buggy in clang, this was detected with a test involving calloc. it is 
possible that other functions are affected as well.

it would be nice if richard pennington could finally invest 3 minutes to 
file a bugreport as he promised and get this annoying issue out of our way.

Re: build musl with clang

[Szabolcs Nagy]

* John Spencer <maillist-musl@barfooze.de> [2012-08-23 15:56:32 +0200]:
> it would be nice if richard pennington could finally invest 3
> minutes to file a bugreport as he promised and get this annoying
> issue out of our way.

it does not have to be him, anyone is fine who has clang
and can reproduce the bug

http://www.openwall.com/lists/musl/2012/05/25/2

for this a minimal calloc implementation is needed that
is similar to the one in musl and clang -ffreestanding
miscompiles it

Re: build musl with clang

[agent]

23.08.2012 19:56, John Spencer пишет:
> i was referring to how you have built musl; musl's configure script 
> detects broken distro toolchains and adds flags so that musl and 
> musl-gcc is built with sysv hash only.
yes, i used configure and it happily ate clang as $CC with no complaints.

23.08.2012 20:42, Szabolcs Nagy пишет:
> * John Spencer <maillist-musl@barfooze.de> [2012-08-23 15:56:32 +0200]:
>> it would be nice if richard pennington could finally invest 3
>> minutes to file a bugreport as he promised and get this annoying
>> issue out of our way.
> it does not have to be him, anyone is fine who has clang
> and can reproduce the bug
>
> http://www.openwall.com/lists/musl/2012/05/25/2
>
> for this a minimal calloc implementation is needed that
> is similar to the one in musl and clang -ffreestanding
> miscompiles it
>
release notes for clang 3.1 say something like it changed behaviour of 
-ffreestanding. i do not have 3.1 right now to check if it changed to a 
desired behaviour

Re: build musl with clang

[Rich Felker]

On Thu, Aug 23, 2012 at 07:11:53PM +0600, agent wrote:
> >there is another known bug in clang which will lead to calloc
> >getting wrongly optimized away, because clang disrespects
> >-ffree-standing. Richard Pennington wanted to reported this to the
> >LLVM maillist months ago, but afaik he still hasn't done this.
> i was investigating the possibility of using clang + musl for
> writing a new program, not for porting existing software, so it may
> be possible to avoid using some functions in reasonable scale, or
> change any component in this bundle.
> and does that bug affect a whole *alloc family or just calloc?

The bug is that clang assumes the memory returned from malloc has
indeterminate contents, which is only a valid assumption on a hosted
implementation. On a freestanding one, malloc is just another ordinary
function with no special semantics. Anyway, based on the wrong
assumption, it optimizes out the zero-fill code that's of the form

for (i=0; i<n; i++) if (mem[i]) mem[i] = 0;

I am not willing to remove the if, because it serves a valuable
purpose: it avoids writing to pages that are already all-zero, which
in turn reduces swap pressure/dirty pages.

Rich

Re: build musl with clang

[agent]

23.08.2012 23:55, Rich Felker пишет:
> The bug is that clang assumes the memory returned from malloc has
> indeterminate contents, which is only a valid assumption on a hosted
> implementation. On a freestanding one, malloc is just another ordinary
> function with no special semantics. Anyway, based on the wrong
> assumption, it optimizes out the zero-fill code that's of the form
>
> for (i=0; i<n; i++) if (mem[i]) mem[i] = 0;
>
> I am not willing to remove the if, because it serves a valuable
> purpose: it avoids writing to pages that are already all-zero, which
> in turn reduces swap pressure/dirty pages.
>
> Rich
even if it assumes the memory has indeterminate contents, indeterminate 
isn't zero so i feel there is no real reason to wipe the whole cycle out 
only because of if statement -- malloc does not have to (and should not) 
zero fill the returned memory.

at least as calloc.c is as separate file in musl it can be compiled with 
a different optimization, though i have never tried to mix code with 
different optimization and i don't know any side effects of it.

Re: build musl with clang

[Rich Felker]

On Fri, Aug 24, 2012 at 11:58:51AM +0600, agent wrote:
> 23.08.2012 23:55, Rich Felker пишет:
> >The bug is that clang assumes the memory returned from malloc has
> >indeterminate contents, which is only a valid assumption on a hosted
> >implementation. On a freestanding one, malloc is just another ordinary
> >function with no special semantics. Anyway, based on the wrong
> >assumption, it optimizes out the zero-fill code that's of the form
> >
> >for (i=0; i<n; i++) if (mem[i]) mem[i] = 0;
> >
> >I am not willing to remove the if, because it serves a valuable
> >purpose: it avoids writing to pages that are already all-zero, which
> >in turn reduces swap pressure/dirty pages.
> >
> >Rich
> even if it assumes the memory has indeterminate contents,
> indeterminate isn't zero so i feel there is no real reason to wipe
> the whole cycle out only because of if statement -- malloc does not
> have to (and should not) zero fill the returned memory.

Any use of indeterminate values results in UB, so the compiler would
be just as free to omit no code at all for the function on a hosted
implementation.

Rich

Re: build musl with clang

[agent]

i have built clang from trunk and tried the calloc test. when test 
program is linked dynamically to libc.so it fails it. if it linked 
statically -- it passes ok.

according to musl build scripts, it is built with -O3 for .so and with 
-Os for .a. so a wrong optimization occurs only on -O3 level

Re: build musl with clang

[Szabolcs Nagy]

* agent <agentprog@gmail.com> [2012-08-24 16:37:32 +0600]:
> i have built clang from trunk and tried the calloc test. when test
> program is linked dynamically to libc.so it fails it. if it linked
> statically -- it passes ok.
> 

so the bug is still present

try to make a minimal testcase

eg.

void *f()
{
	char *p;

	p = malloc(100);
	if (p && p[0])
		p[0] = 0;
	return p;
}


and compile with -O3 -ffreestanding -S

if the check is eliminated then it's a bug

Re: build musl with clang

[agent]

24.08.2012 17:01, Szabolcs Nagy пишет:
> so the bug is still present
>
> try to make a minimal testcase
>
> eg.
>
> void *f()
> {
> 	char *p;
>
> 	p = malloc(100);
> 	if (p && p[0])
> 		p[0] = 0;
> 	return p;
> }
>
>
> and compile with -O3 -ffreestanding -S
>
> if the check is eliminated then it's a bug

f: # @f
# BB#0: # %entry
subl $12, %esp
movl $100, (%esp)
calll malloc
testl %eax, %eax
je .LBB0_2
# BB#1: # %if.then
movb $0, (%eax)
.LBB0_2: # %if.end
addl $12, %esp
ret

i suppose, 'if' is not elliminated.

but if i create a function f2 with contents of musl's calloc it fails 
the test.

then i noticed in musl's calloc a cycle is wrapped into an 'if' with p 
with negative subscript and tried the following:

void *f1() {
char *p;
int i;

p = malloc(100);
if (p[-1])
p[0] = 0;

return p;
}

and that's i we get:

f1: # @f1
# BB#0: # %if.end
subl $12, %esp
movl $100, (%esp)
calll malloc
movb $0, (%eax)
addl $12, %esp
ret

but if we have if (p && p[-1]) -- 'if' is not optimized out.

Re: build musl with clang

[Rich Felker]

On Fri, Aug 24, 2012 at 06:22:11PM +0600, agent wrote:
> f: # @f
> # BB#0: # %entry
> subl $12, %esp
> movl $100, (%esp)
> calll malloc
> testl %eax, %eax
> je .LBB0_2
> # BB#1: # %if.then
> movb $0, (%eax)
> ..LBB0_2: # %if.end
> addl $12, %esp
> ret
> 
> i suppose, 'if' is not elliminated.
> 
> but if i create a function f2 with contents of musl's calloc it
> fails the test.
> 
> then i noticed in musl's calloc a cycle is wrapped into an 'if' with
> p with negative subscript and tried the following:

Does it work if you change the check not to use p[-1] but instead use:

*(size_t *)((char *)p - sizeof(size_t))

Rich

Re: build musl with clang

[agent]

24.08.2012 18:35, Rich Felker пишет:
> *(size_t *)((char *)p - sizeof(size_t))
nothing changed -- does not work

Re: build musl with clang

[Szabolcs Nagy]

* agent <agentprog@gmail.com> [2012-08-24 18:22:11 +0600]:
> p with negative subscript and tried the following:
> 
> void *f1() {
> char *p;
> int i;
> 
> p = malloc(100);
> if (p[-1])
> p[0] = 0;
> 
> return p;
> }
> 
> and that's i we get:
> 
> f1: # @f1
> # BB#0: # %if.end
> subl $12, %esp
> movl $100, (%esp)
> calll malloc
> movb $0, (%eax)
> addl $12, %esp
> ret
> 
> but if we have if (p && p[-1]) -- 'if' is not optimized out.

now that seems wrong (if it was compiled with -ffreestanding)

'if (p[-1])' is dropped even though malloc can put there anything

this should be reported to the clang list

Re: build musl with clang

[Rich Felker]

On Fri, Aug 24, 2012 at 04:59:39PM +0200, Szabolcs Nagy wrote:
> * agent <agentprog@gmail.com> [2012-08-24 18:22:11 +0600]:
> > p with negative subscript and tried the following:
> > 
> > void *f1() {
> > char *p;
> > int i;
> > 
> > p = malloc(100);
> > if (p[-1])
> > p[0] = 0;
> > 
> > return p;
> > }
> > 
> > and that's i we get:
> > 
> > f1: # @f1
> > # BB#0: # %if.end
> > subl $12, %esp
> > movl $100, (%esp)
> > calll malloc
> > movb $0, (%eax)
> > addl $12, %esp
> > ret
> > 
> > but if we have if (p && p[-1]) -- 'if' is not optimized out.
> 
> now that seems wrong (if it was compiled with -ffreestanding)
> 
> 'if (p[-1])' is dropped even though malloc can put there anything
> 
> this should be reported to the clang list

Yes. To clarify, the issue is not that clang is assuming the object
obtained by malloc has indeterminate value. The issue is that clang is
assuming the pointer malloc returns points to an object of size N
beginning at the returned address, and thus that the [-1] index is
invalid pointer arithmetic. This is a malloc-specific assumption and
wrong for freestanding mode where malloc is just an ordinary function
(which is allowed to return a pointer into the middle of an array,
which is what it's doing).

Rich

Re: build musl with clang

[agent]

24.08.2012 23:51, Rich Felker пишет:
> Yes. To clarify, the issue is not that clang is assuming the object 
> obtained by malloc has indeterminate value. The issue is that clang is 
> assuming the pointer malloc returns points to an object of size N 
> beginning at the returned address, and thus that the [-1] index is 
> invalid pointer arithmetic. This is a malloc-specific assumption and 
> wrong for freestanding mode where malloc is just an ordinary function 
> (which is allowed to return a pointer into the middle of an array, 
> which is what it's doing).
i will report this to clang's list (or maybe directly to bugzilla?) as 
soon as i get a subscription confirmation. but i have noticed that not 
only 'if (p[-1])' gets wiped out but any 'if (p[i])'. though the nature 
of this i suppose the same

Re: build musl with clang

[Szabolcs Nagy]

* agent <agentprog@gmail.com> [2012-08-25 00:55:34 +0600]:
> that not only 'if (p[-1])' gets wiped out but any 'if (p[i])'.
> though the nature of this i suppose the same

yes

you can try the same code with another function name
instead of malloc
(eg add a void *foobar(size_t); prototype and use that)

if the generated code is different then that clearly
demonstrates the bug in -ffreestanding

Re: build musl with clang

[Rich Felker]

On Fri, Aug 24, 2012 at 09:04:22PM +0200, Szabolcs Nagy wrote:
> * agent <agentprog@gmail.com> [2012-08-25 00:55:34 +0600]:
> > that not only 'if (p[-1])' gets wiped out but any 'if (p[i])'.
> > though the nature of this i suppose the same
> 
> yes
> 
> you can try the same code with another function name
> instead of malloc
> (eg add a void *foobar(size_t); prototype and use that)
> 
> if the generated code is different then that clearly
> demonstrates the bug in -ffreestanding

Here's an idea for a workaround:

void *not_called_malloc(size_t) __asm__("malloc");
#define malloc not_called_malloc

If that fixes it, it would be an amusing way to present it in the bug
report.

Rich

Re: build musl with clang

[agent]

25.08.2012 06:09, Rich Felker пишет:
> Here's an idea for a workaround:
>
> void *not_called_malloc(size_t) __asm__("malloc");
> #define malloc not_called_malloc
>
> If that fixes it, it would be an amusing way to present it in the bug
> report.
>
> Rich
that is stilled optimized for a plain malloc call even if i call 
not_called_malloc directly and not via a macro. to test the bug i used 
the following function:

void *foo(size_t n) {
static char buf[200];
return buf + 10;
}

and that was the way when 'if' was not optimized out. if i use malloc in 
foo() it is still wiped out.
as far as i know, optimizations are done not only in clang itself but in 
llvm too, so maybe if clang does not notice malloc, llvm does.

Re: build musl with clang

[Szabolcs Nagy]

* agent <agentprog@gmail.com> [2012-08-25 11:57:16 +0600]:
> that is stilled optimized for a plain malloc call even if i call
> not_called_malloc directly and not via a macro. to test the bug i
> used the following function:
> 
> void *foo(size_t n) {
> static char buf[200];
> return buf + 10;
> }
> 

don't define the function, just add a prototype

that's the use case we are trying to test
(clang does not know the definition of
malloc at the point it's used)

a defined function in the same translation unit
of course results different optimizations..

Re: build musl with clang

[agent]

Clang developers commited fix for the bug. i will build clang till 
tomorrow and check if it works with musl.

Re: build musl with clang

[Rich Felker]

On Wed, Aug 29, 2012 at 10:21:50PM +0600, agent wrote:
> Clang developers commited fix for the bug. i will build clang till
> tomorrow and check if it works with musl.

Excellent. Looking forward to hearing if it works.

Rich

Re: build musl with clang

[agent]

29.08.2012 22:59, Rich Felker пишет:
>
> Excellent. Looking forward to hearing if it works.
>
> Rich
clang has been built quite fast, though i was doing a clean build. and i 
can say it works with musl's calloc both in static and dynamic builds.

i can try to run a full test suite like cluts, but i should write some 
wrapper for clang or maybe some kind of spec file as for gcc to make it 
link properly

Re: build musl with clang

[Luca Barbato]

On 8/23/12 7:55 PM, Rich Felker wrote:
> for (i=0; i<n; i++) if (mem[i]) mem[i] = 0;
>
> I am not willing to remove the if, because it serves a valuable
> purpose: it avoids writing to pages that are already all-zero, which
> in turn reduces swap pressure/dirty pages.

Are you sure absolutely sure it does have the intended effect?

lu

Re: build musl with clang

[Rich Felker]

On Fri, Aug 24, 2012 at 07:37:49PM +0200, Luca Barbato wrote:
> On 8/23/12 7:55 PM, Rich Felker wrote:
> >for (i=0; i<n; i++) if (mem[i]) mem[i] = 0;
> >
> >I am not willing to remove the if, because it serves a valuable
> >purpose: it avoids writing to pages that are already all-zero, which
> >in turn reduces swap pressure/dirty pages.
> 
> Are you sure absolutely sure it does have the intended effect?

Yes. And actually the problematic code is not that, but the [-1] index
to inspect whether the chunk was obtained from the heap or via mmap.
In the latter case, no zeroing is needed whatsoever.

Rich

Re: build musl with clang

[John Spencer]

On 08/23/2012 09:53 AM, agent wrote:
>
> if i use musl's ld-musl (as far as i can notice it is just symlink to 
> libc.so) i get a segfault. gdb says:
>
> (gdb) r
> Starting program: /home/agent/dev/musl/musl-0.9.4_clang/lib/t.out
>
> Program received signal SIGSEGV, Segmentation fault.
> 0xb7f9d73a in find_sym () from /lib/ld-musl-i386.so.1
> (gdb) where
> #0  0xb7f9d73a in find_sym () from /lib/ld-musl-i386.so.1
>
> btw, exactly the same things happen when i try it with gcc (4.6.3 from 
> ubuntu).

this sounds as if the binary uses gnu hash as opposed to sysv hash. did 
you use ./configure ?
see FAQ in http://wiki.musl-libc.org


>
> if i compile statically with gcc the program works fine, but with 
> clang it even does not compile (i mean link):
>
> /opt/musl-clang/lib/libc.a(vfprintf.o): In function `printf_core':
> src/stdio/vfprintf.c:(.text+0x1088): undefined reference to `__udivdi3'
> src/stdio/vfprintf.c:(.text+0x10a6): undefined reference to `__umoddi3'
>

these functions are part of libgcc as nsz already stated.

> maybe it is impossible to compile a working musl with clang at this 
> stage, maybe a quick fix can be applied (:
>

there is another known bug in clang which will lead to calloc getting 
wrongly optimized away, because clang disrespects -ffree-standing. 
Richard Pennington wanted to reported this to the LLVM maillist months 
ago, but afaik he still hasn't done this.