Building uclibc ...

I am trying compile a libc with llvm (currently uclibc). I am able to compile uclibc by changing the Rules.mak to use llvm-gcc, llvm-ar, llvm-ad, and not using strip. (I also use the --emit-llvm flag for llvm-gcc). When I run llvm-nm on libc.a (or try to use libc.a) I run into problems. For example, strlen is not defined – llvm-nm shows that strlen.os has __GI_strlen while if I compile with the “normal” tools (gcc, ar, …) strlen.os has __GI_strlen as well as strlen listed (both have the symbol value 00000000).

Any ideas why the archive I create with llvm doesn’t define the strlen (and most other) symbols but does define the __GI_strlen?

I’m sure it is obvious by now, but I am pretty new to LLVM – thanks in advance for your help and time!

~ David

PS. Also, out of curiosity, was someone able to successfully compile all or part of glibc? I saw it was on the open projects page a few years ago (thanks to the old CVS data) but could not find the revision in which it was removed from that list. I suspect that because it was removed, perhaps someone else has figured it out and I could see what they did and try to compile it myself?

Chris,

Can you paste the output of nm for the native GCC version? It's possible
that uclibc is using aliases for these, and it seems very likely that
llvm-nm just isn't printing aliases at all. Anton, do you want to see if
llvm-nm should be extended by this?

afaik, llvm-nm should already handle aliases. :slight_smile: However, it will be
good to see, how uclibc handle mentioned symbols.

I am trying compile a libc with llvm (currently uclibc). I am able to
compile uclibc by changing the Rules.mak to use llvm-gcc, llvm-ar, llvm-ad,
and not using strip. (I also use the --emit-llvm flag for llvm-gcc). When
I run llvm-nm on libc.a (or try to use libc.a) I run into problems. For
example, strlen is not defined -- llvm-nm shows that strlen.os has
__GI_strlen while if I compile with the "normal" tools (gcc, ar, ...)
strlen.os has __GI_strlen as well as strlen listed (both have the symbol
value 00000000).

Any ideas why the archive I create with llvm doesn't define the strlen (and
most other) symbols but does define the __GI_strlen?

Can you paste the output of nm for the native GCC version? It's possible that uclibc is using aliases for these, and it seems very likely that llvm-nm just isn't printing aliases at all. Anton, do you want to see if llvm-nm should be extended by this?

I'm sure it is obvious by now, but I am pretty new to LLVM -- thanks in
advance for your help and time!

Happy to help!

PS. Also, out of curiosity, was someone able to successfully compile all or
part of glibc? I saw it was on the open projects page a few years ago
(thanks to the old CVS data) but could not find the revision in which it was
removed from that list. I suspect that because it was removed, perhaps
someone else has figured it out and I could see what they did and try to
compile it myself?

I don't know of anyone who has tried. If you try it and run into bugs, please file bugzilla entries!

-Chris

I am trying compile a libc with llvm (currently uclibc). I am able to
compile uclibc by changing the Rules.mak to use llvm-gcc, llvm-ar, llvm-ad,
and not using strip. (I also use the --emit-llvm flag for llvm-gcc). When
I run llvm-nm on libc.a (or try to use libc.a) I run into problems. For
example, strlen is not defined – llvm-nm shows that strlen.os has
__GI_strlen while if I compile with the “normal” tools (gcc, ar, …)
strlen.os has __GI_strlen as well as strlen listed (both have the symbol
value 00000000).

Any ideas why the archive I create with llvm doesn’t define the strlen (and
most other) symbols but does define the __GI_strlen?

Can you paste the output of nm for the native GCC version? It’s possible
that uclibc is using aliases for these, and it seems very likely that
llvm-nm just isn’t printing aliases at all. Anton, do you want to see if
llvm-nm should be extended by this?

Sure, thanks for your thoughts … it is a little long so I’ll just include links to the nm output:

nm on the gcc generated native archive: http://www.dound.com/tmp/nm-native.txt
llvm-nm on the llvm generated archive: http://www.dound.com/tmp/nm-llvm.txt

I’m sure it is obvious by now, but I am pretty new to LLVM – thanks in
advance for your help and time!

Happy to help!

PS. Also, out of curiosity, was someone able to successfully compile all or
part of glibc? I saw it was on the open projects page a few years ago
(thanks to the old CVS data) but could not find the revision in which it was
removed from that list. I suspect that because it was removed, perhaps
someone else has figured it out and I could see what they did and try to
compile it myself?

I don’t know of anyone who has tried. If you try it and run into bugs,
please file bugzilla entries!

-Chris

Thanks! ~ David

Okay, this doesn’t look like an alias issue :). WIthout more information, I can’t tell what is going on. Please build the file that produces strlen.os with the -E option to get preprocessed output, and attach it to a bugzilla entry. With that we can figure out what is happening.

Thanks,

-Chris

Thanks, I have submitted this to bugzilla (#1655http://llvm.org/bugs/show_bug.cgi?id=1655). I have included in that report an attachment of the object code generated for one particular function (strcpy) from both GCC and LLVM. I also include the preprocessor output from both (-E) as well as the preprocessor output from LLVM after I make a change to an input file (described in the report #1655) since with that change I am able to get both GCC and LLVM to produce the symbol I need, e.g. T strcpy.

The diffs between the GCC/LLVM outputs and the two LLVM preprocessor outputs is pretty small, so hopefully someone who is knowledgeable about LLVM will be able to figure out what is going wrong (or what I’m doing wrong).

Thanks again for the help!

~ David