llvm dev - Jul 2011 - [LLVMdev] dragon egg adding extra characters to function names

Hello,

I'm looking at compiling some pieces of the standard library with llvm but
I'm running into problems with some functions being renamed by dragonegg.
For example, when I compile the acos implementation with plain gcc I get:

$ nm acos.o
0000000000000000 r .LC1
0000000000000048 r .LC10
0000000000000050 r .LC11
0000000000000058 r .LC12
0000000000000060 r .LC13
0000000000000068 r .LC14
0000000000000070 r .LC15
0000000000000008 r .LC2
0000000000000010 r .LC3
0000000000000018 r .LC4
0000000000000020 r .LC5
0000000000000028 r .LC6
0000000000000030 r .LC7
0000000000000038 r .LC8
0000000000000040 r .LC9
0000000000000000 T __GI_acos
0000000000000000 T __ieee754_acos
                 U __ieee754_sqrt
0000000000000000 T acos

but when I compile with dragonegg, I get:

$ llvm-nm acos.bc.o
         T __GI_acos
         T acos
         T __ieee754_acos
         U __ieee754_sqrt

Why does LLVM do this? I assume that it has something to do with the fact
that LLVM treats the function "acos" as special and so doesn't
want it to be
redefined, is that correct? I've been running a post-processing pass that
finds functions and function references with the character and removes it,
but this kind of messes up my workflow. Is there anyway to tell LLVM to not
do this?

Thanks.
-- 
gregory malecha
http://www.people.fas.harvard.edu/~gmalecha/
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20110725/ff7f73ad/attachment.html>

Hi Gregory,
> I'm looking at compiling some pieces of the standard library with llvm
but I'm
> running into problems with some functions being renamed by dragonegg. For
> example, when I compile the acos implementation with plain gcc I get:
>
> $ nm acos.o
> 0000000000000000 r .LC1
> 0000000000000048 r .LC10
> 0000000000000050 r .LC11
> 0000000000000058 r .LC12
> 0000000000000060 r .LC13
> 0000000000000068 r .LC14
> 0000000000000070 r .LC15
> 0000000000000008 r .LC2
> 0000000000000010 r .LC3
> 0000000000000018 r .LC4
> 0000000000000020 r .LC5
> 0000000000000028 r .LC6
> 0000000000000030 r .LC7
> 0000000000000038 r .LC8
> 0000000000000040 r .LC9
> 0000000000000000 T __GI_acos
> 0000000000000000 T __ieee754_acos
>                   U __ieee754_sqrt
> 0000000000000000 T acos
>
> but when I compile with dragonegg, I get:
>
> $ llvm-nm acos.bc.o
>           T __GI_acos
>           T acos
>           T __ieee754_acos
>           U __ieee754_sqrt
I don't see any functions being renamed: the names seem to be the same just
in a different order...

Ciao, Duncan.

Hi Duncan,

Ah, non-unicode email... In the llvm output there should be a "1"
character,
i.e. (char) 0x01, prepended to acos and __GI_acos. I'm unable to get it on
smaller things, but it happens when I try to compile uClibc with llvm. I've
attached the .o and the .bc for comparison. The text file is the result
after preprocessing (to avoid having to download a bunch of stuff).

Here is the compile line that I'm running for the llvm compilation:
llvm-gcc -emit-llvm -S -c pp.c -o /tmp/tmpU_bCHo.ll -c
llvm-as /tmp/tmpU_bCHo.ll -o=pp.bc.o
(note that llvm-gcc is gcc-4.5 setup to generate assembly when it gets
-emit-llvm).

The non-llvm compilation is from:
gcc-4.5 -c pp.c -o pp.o

I thought this was something coded into llvm, but maybe it is just my
scripts messing things up somehow...

On Tue, Jul 26, 2011 at 12:06 AM, Duncan Sands <baldrick at free.fr>
wrote:
> Hi Gregory,
>
> > I'm looking at compiling some pieces of the standard library with
llvm
> but I'm
> > running into problems with some functions being renamed by dragonegg.
For
> > example, when I compile the acos implementation with plain gcc I get:
> >
> > $ nm acos.o
> > 0000000000000000 r .LC1
> > 0000000000000048 r .LC10
> > 0000000000000050 r .LC11
> > 0000000000000058 r .LC12
> > 0000000000000060 r .LC13
> > 0000000000000068 r .LC14
> > 0000000000000070 r .LC15
> > 0000000000000008 r .LC2
> > 0000000000000010 r .LC3
> > 0000000000000018 r .LC4
> > 0000000000000020 r .LC5
> > 0000000000000028 r .LC6
> > 0000000000000030 r .LC7
> > 0000000000000038 r .LC8
> > 0000000000000040 r .LC9
> > 0000000000000000 T __GI_acos
> > 0000000000000000 T __ieee754_acos
> >                   U __ieee754_sqrt
> > 0000000000000000 T acos
> >
> > but when I compile with dragonegg, I get:
> >
> > $ llvm-nm acos.bc.o
> >           T __GI_acos
> >           T acos
> >           T __ieee754_acos
> >           U __ieee754_sqrt
>
> I don't see any functions being renamed: the names seem to be the same
just
> in a different order...
>
> Ciao, Duncan.
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>


-- 
gregory malecha
http://www.people.fas.harvard.edu/~gmalecha/
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20110726/01d134de/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pp.bc.o
Type: application/x-object
Size: 1884 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20110726/01d134de/attachment.o>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pp.o
Type: application/x-object
Size: 4328 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20110726/01d134de/attachment-0001.o>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pp.c
Type: text/x-csrc
Size: 42431 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20110726/01d134de/attachment.c>