[LLVMbugs] [Bug 1655] New: uclibc build problem

[bugzilla-daemon at cs.uiuc.edu]

http://llvm.org/bugs/show_bug.cgi?id=1655

           Summary: uclibc build problem
           Product: new-bugs
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Keywords: miscompilation
          Severity: normal
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: dgu at stanford.edu
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=1117)
 --> (http://llvm.org/bugs/attachment.cgi?id=1117)
Contains files referenced in my message (object and preprocessor output for
LLVM and GCC)

I recently exchanged some emails regarding this on the LLVM devlist and Chris
suggested that I post my problems here after some discussion.  The emails from
the mailing list (from 12-Sep-2007) are included below.

Note: I have referenced a number of files below.  These are all included in the
attached tarball.

I have reduced the scope of my problem to compiling a single file in uclibc:
/libc/string/generic/strcpy.c (though the same problem occurs across most
functions defined in libc).

The output object (strcpy.os) has the following symbols (as per llvm-nm, nm):
When compiling with LLVM (source object attached as strcpy.llvm.os):
         T 
__GI_strcpy
When compiling with GCC (source object attached as strcpy.gcc.os):
00000000 T __GI_strcpy
00000000 T strcpy

This is a problem because I would expect both to contain the same symbols (and
in particular because I want to link with this object file and be able to call
strcpy :]).

As requested by Chris, I compiled with -E to get the preprocessor output and
have attached those files as well (strcpy.gcc.e, strcpy.llvm.e).  A diff shows
that they are essentially identical except that each compiler references its
own stddef.h header.

With a small modification (described in the readme which I describe below), I
can get the object files generated by GCC and LLVM to have the following
symbol:
GCC:00000000 T strcpy
LLVM:         T strcpy

The only difference in the output from -E is (the change is made to the uclibc
file include/libc-symbols.h ... the resulting output from -E for LLVM is
attached as strcpy.remdefs.llvm.e):
292c292
< extern __typeof (strcpy) strcpy __asm__ ("" "__GI_strcpy") __attribute__
((visibility ("hidden")));
---
>
314c314
< extern __typeof (strcpy) __EI_strcpy __asm__("" "strcpy"); extern __typeof
(strcpy) __EI_strcpy __attribute__((alias ("" "__GI_strcpy")));
---
>

Any ideas on what the problem is?  My compiler options are -O2 -Wall (plus
--emit-llvm for llvm-gcc).  I am using gcc 4.2.1 and llvm-gcc 4.2.0.

I also included a readme (BUILD_W_LLVM_README) on the simple changes (to the
configuration and makefile) which need to be made to build uclibc-0.9.29 with
LLVM in case you would like to try building it on your system and see if you
have similar results.  If anyone is interested, I can upload the modified
uclibc config and make files if you prefer just to use those instead of making
the changes per the readme.


Thanks in advance for any light you can shed on these issues!


************************************
*** EMAILS FROM THE MAILING LIST ***
************************************
On 9/12/07, Chris Lattner <sabre at nondot.org > wrote:

    On Wed, 12 Sep 2007, David Underhill wrote:
    > 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?

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

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


-------------------------------
FOLLOW-UP EMAIL ...
-------------------------------
On 9/12/07, Chris Lattner <sabre at nondot.org > wrote:
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.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.