search for: non_lazy_ptr

I have a problem where my LLVM-generated code works on Linux but not on OS X, and the problem involves non_lazy_ptr. I have an external symbol named "@gc_safepoint_map", which is generated by the linker's GCStrategy plugin. Since it is not generated until link time, I declared it as an external symbol so that the modules that use it can compile without error. Here's what the generated IR look...

...;ve got a case where I am attempting to pass the address of a static symbol from a module written in Tart (the language I am working on), to a module written in C (which is part of Tart's runtime library). This works fine on Linux, but fails on OS X because the address being passed is the "non_lazy_ptr" symbol, not the symbol itself. In my .bc file, I've got code that looks like this: @gc_safepoint_map = external global [0 x i32] ; <[0 x i32]*> [#uses=1] %init = invoke {} @GC_init(i32* getelementptr inbounds ([0 x i32]* @gc_safepoint_map, i32 0, i32 0)) to labe...

...simplifications to the asmprinters. One thing that is driving me nuts is that the asmprinters currently "reverse engineer" a lot of information when printing an operand that isel had when it created it. I'm specifically talking about all the suffixes generated by isel, like $non_lazy_ptr, @TLSGD, @NTPOFF, (%rip) etc. These are all "magic" things that the assembler uses (for example, it generates a reference to a global's GOT entry instead of to the global itself). The thing that is really frustrating to me is that the asmprinters need to reverse engineer what...

...darwin. They are likely not your fault. I'm trying to get a PPC build bot setup (arxan_bellini), and so far it's dying here: Linking CXX shared library ../../lib/libgtest.dylib Undefined symbols: "vtable for llvm::raw_ostream", referenced from: __ZTVN4llvm11raw_ostreamE$non_lazy_ptr in gtest.cc.o __ZTVN4llvm11raw_ostreamE$non_lazy_ptr in gtest-death-test.cc.o __ZTVN4llvm11raw_ostreamE$non_lazy_ptr in gtest-port.cc.o __ZTVN4llvm11raw_ostreamE$non_lazy_ptr in gtest-typed-test.cc.o "llvm::raw_os_ostream::~raw_os_ostream()", referenced from: llv...

...ts on x86-32 with -fomit-frame-pointer (which is not the default): result of -fPIC (equivalent to -fpic on Darwin): _foo: call L3 "L00000000001$pb": popl %ecx << gets value of PC into %ecx (other registers can be used) movl L_x$non_lazy_ptr-"L00000000001$pb"(%ecx), %eax << gets &x; PC relative movl (%eax), %eax << gets x; indirect ret .comm _x,4,2 .section __IMPORT,__pointers,non_lazy_symbol_pointers L_x$non_lazy_ptr: .indirect_symbol _x << magic cook...

...more specific question about compiling native code: When I use llc to generate a .s file, and then I try to assemble it using 'as', I get tons of errors - it appears to be choking on lines like the following: movl L"_tart.core.Iterable<tart.core.String>:type"$non_lazy_ptr, %eax The error I get is: out/Debug/test/tart/FileStreamTest.out.s:95:junk `"_tart.core.Iterable<tart.core.String>:type"$non_lazy_ptr' after expression (plus a few hundred more like it.) -- Talin

...> of > things I really dislike about C++ is trying to interpret mangled names > in a stack trace.) I'm counting on LLVM to be able to quote/escape > everything as needed. It seems the quotes aren't being put in the right places when constructing "$stub" and "$non_lazy_ptr" names, they should look like this: "L(complicated<expression>)$non_lazy_ptr" with the quotes outside. This hasn't come up before because the only places quotes occur now is in ObjectiveC names which don't use stubs or non-lazy pointers. I guess it ought to work,...

...llvm::TargetLoweringObjectFileMachOin libLLVMCodeGen.a(TargetLoweringObjectFileImpl.cpp.o) typeinfo for llvm::TargetLoweringObjectFileCOFFin libLLVMCodeGen.a(TargetLoweringObjectFileImpl.cpp.o) "llvm::GuaranteedTailCallOpt", referenced from: __ZN4llvm21GuaranteedTailCallOptE$non_lazy_ptr in libLLVMCodeGen.a(Analysis.cpp.o) "llvm::TargetLoweringObjectFile::SectionForGlobal(llvm::GlobalValue const*, llvm::SectionKind, llvm::Mangler*, llvm::TargetMachine const&) const", referenced from: llvm::AsmPrinter::EmitGlobalVariable(llvm::GlobalVariable const*)in libLLVMAs...

...> It's not exactly tweaking magic knobs. It's doing something that's > already done -- putting the information in the TAI object, and > allowing the specific back-end to set the appropriate strings. It seems to me, that simple strings / bools there are not enough :) "$non_lazy_ptr" emission is already in asm printers (in 2 places!). The "L" prefix is PrivateGlobalPrefix (so PersonalityPrefix is really duplicate). That's why I thought about factoring such stuff into separate hooks. I'm really worrying, that number of such strings / bools can be increase...

Anton, >> Can I ask what platform ABI's are documented other than Itanium ? > I'd bet all platform ABI are more or less documented. Right. Maybe we should collect references and do some LLVM PIC documentation and put it on LLVM website ? >> I need to get to understand PIC on x86, x86_64 and PowerPC for the COFF >> and MachO backends. > ABI is normally induced

...la/build/Release//lib -L/Users/me/Work/code/ llvm-2.4/Release//lib -lLMABE -lPartition -lLLVMBitReader - lLLVMAnalysis -lLLVMTarget -lLLVMCore -lLLVMSupport -lLLVMSystem - lpthread -lm Undefined symbols: "llvm::FindUsedTypes::ID", referenced from: __ZN4llvm13FindUsedTypes2IDE$non_lazy_ptr in libLMABE.a(LMAWriter.o) "typeinfo for llvm::FindUsedTypes", referenced from: __ZTIN4llvm13FindUsedTypesE$non_lazy_ptr in libLMABE.a(LMAWriter.o) ld: symbol(s) not found collect2: ld returned 1 exit status make[2]: *** [/Users/me/Work/code/synphony/llvmllila/build/Release/...

...not exactly tweaking magic knobs. It's doing something that's >> already done -- putting the information in the TAI object, and >> allowing the specific back-end to set the appropriate strings. > It seems to me, that simple strings / bools there are not enough :) > "$non_lazy_ptr" emission is already in asm printers (in 2 places!). > The > "L" prefix is PrivateGlobalPrefix (so PersonalityPrefix is really > duplicate). That's why I thought about factoring such stuff into > separate hooks. I'm really worrying, that number of such strings /...

...ied .align 4 .global foo .thumb .thumb_func foo: /* these lines are from compiler's assembly output($(CC) -S): * extern int data_table[]; * int *wheres_data_table(void) { * return &data_table[0]; * } */ movw r1, :lower16:(L_data_table$non_lazy_ptr-(LPC0_0+4)) movt r1, :upper16:(L_data_table$non_lazy_ptr-(LPC0_0+4)) LPC0_0: add r1, pc ldr r1, [r1] bx lr .section __DATA,__nl_symbol_ptr,non_lazy_symbol_pointers .align 2 L_data_table$non_lazy_ptr: .indirect_symbol _data_table .long 0...

Hi Ashi, > ld: illegal text-relocation to _data_table in table.o from foo in > use_table.o for architecture armv7 It looks like you're using iOS. I'm not familiar with the exact workings of that platform, but I think a similar message would occur in ELF-land. If iOS *is* comparable, your issue is that symbols in dynamically loaded objects can't (usually) be referenced directly

.../me/Work/code/ > llvm-2.4/Release//lib -lLMABE -lPartition -lLLVMBitReader - > lLLVMAnalysis -lLLVMTarget -lLLVMCore -lLLVMSupport -lLLVMSystem - > lpthread -lm > Undefined symbols: > "llvm::FindUsedTypes::ID", referenced from: > __ZN4llvm13FindUsedTypes2IDE$non_lazy_ptr in > libLMABE.a(LMAWriter.o) > "typeinfo for llvm::FindUsedTypes", referenced from: > __ZTIN4llvm13FindUsedTypesE$non_lazy_ptr in > libLMABE.a(LMAWriter.o) > ld: symbol(s) not found > collect2: ld returned 1 exit status > make[2]: *** [/Users/me/Work/cod...

...-storage.o _antispam_mailbox_transaction_commit in antispam-storage.o _antispam_mailbox_transaction_rollback in antispam-storage.o "_t_str_ucase", referenced from: _get_setting in antispam-plugin.o "_default_pool", referenced from: _default_pool$non_lazy_ptr in signature.o _default_pool$non_lazy_ptr in antispam-storage.o _default_pool$non_lazy_ptr in dspam-exec.o "_mail_module_register", referenced from: _antispam_mail_module in antispam-storage.o "_mail_storage_set_error", referenced from: _signatu...

...; <i32> [#uses=1] 12. ret i32 %0 13. } 14. 15. declare void @llvm.memory.barrier(i1, i1, i1, i1, i1) nounwind compiled with: 1. llc -mcpu=core2 -mattr=+sse2,+sse3 -f -o test.s test.bc becomes 1. .text 2. .align 4,0x90 3. .globl __Z3foov 4. __Z3foov: 5. movl L_a$non_lazy_ptr, %eax 6. movl $1, (%eax) 7. nop 8. movl L_b$non_lazy_ptr, %eax 9. movl (%eax), %eax 10. ret 11. 12. .section __IMPORT,__pointers,non_lazy_symbol_pointers 13. L_a$non_lazy_ptr: 14. .indirect_symbol _a 15. .long 0 16. L_b$non_lazy_ptr: 17. .indirect_symbol _b 18. .long 0 19. .subsections_via_...

...< 1000; ++i) > Array[i] += X; > } > > Compile with -O3 on OS/X gave me this: > > _test: > mflr r5 > bcl 20,31,"L00000000001$pb" > "L00000000001$pb": > mflr r2 > mtlr r5 > addis r4,r2,ha16(L_Array$non_lazy_ptr-"L00000000001$pb") > li r2,0 > lwz r9,lo16(L_Array$non_lazy_ptr-"L00000000001$pb")(r4) > li r4,1000 > mtctr r4 > L9: > lwzx r7,r2,r9 ; load > add r6,r7,r3 ; add > stwx r6,r2,r9...

Anton Korobeynikov wrote: > Hello Talin, > >> Yes exactly. I'm on OS X (x86), and I'm not specifying a target - I >> assumed that it would choose sensible defaults... >> > Could you please provide a .bc testcase? There can be multiple issues, > but at the first glance it seems, that names were not properly mangled. > I've created bug

Hello Talin, > Yes exactly. I'm on OS X (x86), and I'm not specifying a target - I > assumed that it would choose sensible defaults... Could you please provide a .bc testcase? There can be multiple issues, but at the first glance it seems, that names were not properly mangled. -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint Petersburg