search for: __gi_acos

...00058 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...

...00068 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_s...

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...

Hi Gregory, > 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). this is normal, and should not tur...