* build musl with clang
@ 2012-08-23 7:53 agent
2012-08-23 9:23 ` Szabolcs Nagy
` (2 more replies)
0 siblings, 3 replies; 29+ messages in thread
From: agent @ 2012-08-23 7:53 UTC (permalink / raw)
To: musl
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
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: build musl with clang
2012-08-23 7:53 build musl with clang agent
@ 2012-08-23 9:23 ` Szabolcs Nagy
2012-08-23 10:25 ` agent
2012-08-23 12:24 ` Rich Felker
2012-08-23 12:24 ` John Spencer
2 siblings, 1 reply; 29+ messages in thread
From: Szabolcs Nagy @ 2012-08-23 9:23 UTC (permalink / raw)
To: musl
* 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
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: build musl with clang
2012-08-23 9:23 ` Szabolcs Nagy
@ 2012-08-23 10:25 ` agent
0 siblings, 0 replies; 29+ messages in thread
From: agent @ 2012-08-23 10:25 UTC (permalink / raw)
To: musl
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!
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: build musl with clang
2012-08-23 7:53 build musl with clang agent
2012-08-23 9:23 ` Szabolcs Nagy
@ 2012-08-23 12:24 ` Rich Felker
2012-08-23 13:11 ` agent
2012-08-23 12:24 ` John Spencer
2 siblings, 1 reply; 29+ messages in thread
From: Rich Felker @ 2012-08-23 12:24 UTC (permalink / raw)
To: musl
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
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: build musl with clang
2012-08-23 12:24 ` Rich Felker
@ 2012-08-23 13:11 ` agent
2012-08-23 13:56 ` John Spencer
2012-08-23 17:55 ` Rich Felker
0 siblings, 2 replies; 29+ messages in thread
From: agent @ 2012-08-23 13:11 UTC (permalink / raw)
To: musl
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?
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: build musl with clang
2012-08-23 13:11 ` agent
@ 2012-08-23 13:56 ` John Spencer
2012-08-23 14:42 ` Szabolcs Nagy
2012-08-23 15:12 ` agent
2012-08-23 17:55 ` Rich Felker
1 sibling, 2 replies; 29+ messages in thread
From: John Spencer @ 2012-08-23 13:56 UTC (permalink / raw)
To: musl; +Cc: Richard Pennington
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.
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: build musl with clang
2012-08-23 13:56 ` John Spencer
@ 2012-08-23 14:42 ` Szabolcs Nagy
2012-08-23 15:12 ` agent
1 sibling, 0 replies; 29+ messages in thread
From: Szabolcs Nagy @ 2012-08-23 14:42 UTC (permalink / raw)
To: musl
* 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
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: build musl with clang
2012-08-23 13:56 ` John Spencer
2012-08-23 14:42 ` Szabolcs Nagy
@ 2012-08-23 15:12 ` agent
1 sibling, 0 replies; 29+ messages in thread
From: agent @ 2012-08-23 15:12 UTC (permalink / raw)
To: musl
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
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: build musl with clang
2012-08-23 13:11 ` agent
2012-08-23 13:56 ` John Spencer
@ 2012-08-23 17:55 ` Rich Felker
2012-08-24 5:58 ` agent
2012-08-24 17:37 ` Luca Barbato
1 sibling, 2 replies; 29+ messages in thread
From: Rich Felker @ 2012-08-23 17:55 UTC (permalink / raw)
To: musl
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
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: build musl with clang
2012-08-23 17:55 ` Rich Felker
@ 2012-08-24 5:58 ` agent
2012-08-24 6:06 ` Rich Felker
2012-08-24 17:37 ` Luca Barbato
1 sibling, 1 reply; 29+ messages in thread
From: agent @ 2012-08-24 5:58 UTC (permalink / raw)
To: musl
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.
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: build musl with clang
2012-08-24 5:58 ` agent
@ 2012-08-24 6:06 ` Rich Felker
2012-08-24 10:37 ` agent
0 siblings, 1 reply; 29+ messages in thread
From: Rich Felker @ 2012-08-24 6:06 UTC (permalink / raw)
To: musl
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
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: build musl with clang
2012-08-24 6:06 ` Rich Felker
@ 2012-08-24 10:37 ` agent
2012-08-24 11:01 ` Szabolcs Nagy
0 siblings, 1 reply; 29+ messages in thread
From: agent @ 2012-08-24 10:37 UTC (permalink / raw)
To: musl
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
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: build musl with clang
2012-08-24 10:37 ` agent
@ 2012-08-24 11:01 ` Szabolcs Nagy
2012-08-24 12:22 ` agent
0 siblings, 1 reply; 29+ messages in thread
From: Szabolcs Nagy @ 2012-08-24 11:01 UTC (permalink / raw)
To: musl
* 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
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: build musl with clang
2012-08-24 11:01 ` Szabolcs Nagy
@ 2012-08-24 12:22 ` agent
2012-08-24 12:35 ` Rich Felker
2012-08-24 14:59 ` Szabolcs Nagy
0 siblings, 2 replies; 29+ messages in thread
From: agent @ 2012-08-24 12:22 UTC (permalink / raw)
To: musl
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.
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: build musl with clang
2012-08-24 12:22 ` agent
@ 2012-08-24 12:35 ` Rich Felker
2012-08-24 12:39 ` agent
2012-08-24 14:59 ` Szabolcs Nagy
1 sibling, 1 reply; 29+ messages in thread
From: Rich Felker @ 2012-08-24 12:35 UTC (permalink / raw)
To: musl
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
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: build musl with clang
2012-08-24 12:22 ` agent
2012-08-24 12:35 ` Rich Felker
@ 2012-08-24 14:59 ` Szabolcs Nagy
2012-08-24 17:51 ` Rich Felker
1 sibling, 1 reply; 29+ messages in thread
From: Szabolcs Nagy @ 2012-08-24 14:59 UTC (permalink / raw)
To: musl
* 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
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: build musl with clang
2012-08-24 14:59 ` Szabolcs Nagy
@ 2012-08-24 17:51 ` Rich Felker
2012-08-24 18:55 ` agent
0 siblings, 1 reply; 29+ messages in thread
From: Rich Felker @ 2012-08-24 17:51 UTC (permalink / raw)
To: musl
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
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: build musl with clang
2012-08-24 17:51 ` Rich Felker
@ 2012-08-24 18:55 ` agent
2012-08-24 19:04 ` Szabolcs Nagy
0 siblings, 1 reply; 29+ messages in thread
From: agent @ 2012-08-24 18:55 UTC (permalink / raw)
To: musl
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
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: build musl with clang
2012-08-24 18:55 ` agent
@ 2012-08-24 19:04 ` Szabolcs Nagy
2012-08-25 0:09 ` Rich Felker
0 siblings, 1 reply; 29+ messages in thread
From: Szabolcs Nagy @ 2012-08-24 19:04 UTC (permalink / raw)
To: musl
* 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
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: build musl with clang
2012-08-24 19:04 ` Szabolcs Nagy
@ 2012-08-25 0:09 ` Rich Felker
2012-08-25 5:57 ` agent
0 siblings, 1 reply; 29+ messages in thread
From: Rich Felker @ 2012-08-25 0:09 UTC (permalink / raw)
To: musl
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
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: build musl with clang
2012-08-25 0:09 ` Rich Felker
@ 2012-08-25 5:57 ` agent
2012-08-25 8:03 ` Szabolcs Nagy
0 siblings, 1 reply; 29+ messages in thread
From: agent @ 2012-08-25 5:57 UTC (permalink / raw)
To: musl
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.
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: build musl with clang
2012-08-25 5:57 ` agent
@ 2012-08-25 8:03 ` Szabolcs Nagy
2012-08-29 16:21 ` agent
0 siblings, 1 reply; 29+ messages in thread
From: Szabolcs Nagy @ 2012-08-25 8:03 UTC (permalink / raw)
To: musl
* 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..
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: build musl with clang
2012-08-23 17:55 ` Rich Felker
2012-08-24 5:58 ` agent
@ 2012-08-24 17:37 ` Luca Barbato
2012-08-24 17:52 ` Rich Felker
1 sibling, 1 reply; 29+ messages in thread
From: Luca Barbato @ 2012-08-24 17:37 UTC (permalink / raw)
To: musl
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
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: build musl with clang
2012-08-24 17:37 ` Luca Barbato
@ 2012-08-24 17:52 ` Rich Felker
0 siblings, 0 replies; 29+ messages in thread
From: Rich Felker @ 2012-08-24 17:52 UTC (permalink / raw)
To: musl
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
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: build musl with clang
2012-08-23 7:53 build musl with clang agent
2012-08-23 9:23 ` Szabolcs Nagy
2012-08-23 12:24 ` Rich Felker
@ 2012-08-23 12:24 ` John Spencer
2 siblings, 0 replies; 29+ messages in thread
From: John Spencer @ 2012-08-23 12:24 UTC (permalink / raw)
To: musl; +Cc: Richard Pennington
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.
^ permalink raw reply [flat|nested] 29+ messages in thread
end of thread, other threads:[~2012-08-29 17:50 UTC | newest]
Thread overview: 29+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-08-23 7:53 build musl with clang agent
2012-08-23 9:23 ` Szabolcs Nagy
2012-08-23 10:25 ` agent
2012-08-23 12:24 ` Rich Felker
2012-08-23 13:11 ` agent
2012-08-23 13:56 ` John Spencer
2012-08-23 14:42 ` Szabolcs Nagy
2012-08-23 15:12 ` agent
2012-08-23 17:55 ` Rich Felker
2012-08-24 5:58 ` agent
2012-08-24 6:06 ` Rich Felker
2012-08-24 10:37 ` agent
2012-08-24 11:01 ` Szabolcs Nagy
2012-08-24 12:22 ` agent
2012-08-24 12:35 ` Rich Felker
2012-08-24 12:39 ` agent
2012-08-24 14:59 ` Szabolcs Nagy
2012-08-24 17:51 ` Rich Felker
2012-08-24 18:55 ` agent
2012-08-24 19:04 ` Szabolcs Nagy
2012-08-25 0:09 ` Rich Felker
2012-08-25 5:57 ` agent
2012-08-25 8:03 ` Szabolcs Nagy
2012-08-29 16:21 ` agent
2012-08-29 16:59 ` Rich Felker
2012-08-29 17:50 ` agent
2012-08-24 17:37 ` Luca Barbato
2012-08-24 17:52 ` Rich Felker
2012-08-23 12:24 ` John Spencer
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).