search for: indirect_symbol

...peated a few times combined.s:1330: Error: unknown pseudo-op: `.cstring' combined.s:1335: Error: junk at end of line, first unrecognized character is `,' .. repeated many times combined.s:1366: Error: character following name is not '#' combined.s:1370: Error: unknown pseudo-op: `.indirect_symbol' combined.s:1375: Error: unknown pseudo-op: `.lazy_symbol_pointer' combined.s:1377: Error: unknown pseudo-op: `.indirect_symbol' .. repeated a few times combined.s:1393: Error: unknown pseudo-op: `.subsections_via_symbols' Thank you, -aa -------------- next part --------------...

...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 cookie for indirect references, must be in this magic section .long 0 Result of -mdynamic-no-pic: _foo: movl L_x$non_lazy_ptr, %eax << &x, not PC relative movl (%eax), %eax << gets x; indirect ret...

Hello, > combined.s:1370: Error: unknown pseudo-op: `.indirect_symbol' > combined.s:1375: Error: unknown pseudo-op: `.lazy_symbol_pointer' > combined.s:1377: Error: unknown pseudo-op: `.indirect_symbol' > .. repeated a few times > combined.s:1393: Error: unknown pseudo-op: `.subsections_via_symbols' Looks like you've generated assemble...

...nwind unwind label %catch When lowered to assembly, the code looks like this on OS X: Ltmp426: movl L_gc_safepoint_map$non_lazy_ptr, %eax movl %eax, (%esp) calll _GC_init (and later on in the same file): L_gc_safepoint_map$non_lazy_ptr: .indirect_symbol _gc_safepoint_map .long 0 This looks correct to me - it's dereferencing the non_lazy_ptr version of the global. The GC_init function, which is written in C, simply looks like this: void GC_init(size_t * safepointMap) { // ... details omitted... } On Linux, everyt...

...valid character '(' in mnemonic crc32_x86.S:271: Error: invalid character '(' in mnemonic crc32_x86.S:279: Error: bad or irreducible absolute expression crc32_x86.S:279: Error: junk at end of line, first unrecognized character is `,' crc32_x86.S:281: Error: unknown pseudo-op: `.indirect_symbol' crc32_x86.S:293: Warning: .size pseudo-op used outside of .def/.endef ignored. crc32_x86.S:293: Error: junk at end of line, first unrecognized character is `L' crc32_x86.S:302: Error: junk at end of line, first unrecognized character is `-' [[alternative HTML version deleted]]

On Monday 04 January 2010 05:16:40 Jeffrey Yasskin wrote: > On Sun, Jan 3, 2010 at 10:50 PM, Jon Harrop <jon at ffconsultancy.com> wrote: > > LLVM's TCO already handles mutual recursion. > > Only for fastcc functions Yes. > compiled with -tailcallopt, right? If you use the compiler, yes. > http://llvm.org/docs/CodeGenerator.html#tailcallopt > > I believe

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

On Sun, Jan 3, 2010 at 10:50 PM, Jon Harrop <jon at ffconsultancy.com> wrote: > On Monday 04 January 2010 03:33:06 Simon Harris wrote: >> On 04/01/2010, at 3:01 PM, Jon Harrop wrote: >> > I am certainly interested in tail calls because my HLVM project relies >> > upon LLVM's tail call elimination. However, I do not understand what tail >> > calls LLVM

..._foo, STT_TLS # aka @tls_object - MCSA_ELF_TypeCommon, /// .type _foo, STT_COMMON # aka @common - MCSA_ELF_TypeNoType, /// .type _foo, STT_NOTYPE # aka @notype - MCSA_Global, /// .globl - MCSA_Hidden, /// .hidden (ELF) - MCSA_IndirectSymbol, /// .indirect_symbol (MachO) - MCSA_Internal, /// .internal (ELF) - MCSA_LazyReference, /// .lazy_reference (MachO) - MCSA_Local, /// .local (ELF) - MCSA_NoDeadStrip, /// .no_dead_strip (MachO) - MCSA_PrivateExtern, /// .private_extern (MachO) - MCSA_Protected,...

...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_symbols Is the problem related to the fact that I get i386 from uname -m? If so, how can I tell override this setting during compilation? Thanks, Luke

On 19 December 2016 at 09:58, Jojo Ma <jojo.ma at linaro.org> wrote: > /home/likewise-open/SPREADTRUM/jojo.ma/jojoma/source/llvm/llvm-linaro/llvm/llvm/test/CodeGen/Thumb2/machine-licm.ll:88:10: > error: expected string not found in input > ; CHECK: movw {{(r[0-9])|(lr)}}, #32768 > ^ > <stdin>:56:2: note: scanning from here > movw r12, #32768 > ^ Hi

...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 .subsections_via_symbols /* ==end use_table_m2.s== */ /* ==begin test.c ==*/ extern int data_table[]; int main(void) { int a = data_table[0]; return 0; } /* ==end test.c ==*/ /* ==Makefile== */ CC = /Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin...

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

Ok, I *might* be getting this from the assembly code. The assembly code has: L_llvm_gc_root_chain$non_lazy_ptr: .indirect_symbol _llvm_gc_root_chain .long 0 and I see it being used in the function preamble. Is that a ref to an extern symbol or the def? I.e., is it referring to StackEntry *llvm_gc_root_chain; that I must have in my GC C code? (semispace.c has it) SO! I might be getting this. The shadow sta...

Hi Bill, > Please read this proposal and send me your comments, suggestions, and concerns. this proposal looks great to me. Thanks for working on it. I have a few minor comments, see below. > //===-------------------------- > // The 'landingpad' Instruction > // > > The 'landingpad' instruction replaces the current 'llvm.eh.exception' and >

...do this because the machinery for printing out the correct global value's representation in assembly is already in the code. So it knows how to print: .long ___gxx_personality_v0+4 at GOTPCREL as opposed to .long L___gxx_personality_v0$non_lazy_ptr-. L___gxx_personality_v0$non_lazy_ptr: .indirect_symbol ___gxx_personality_v0 At least for the Mac, it's much easier to do it the GV way... :-) > Finally, rather than baking cleanups, filters etc into the IR, I suppose the > landingpad instruction could just be: > > %res = landingpad<some type> data<ty> > > For sta...

What? Yet another EH proposal?! This one is different from the others in that I'm planning to start implementing this shortly. But I want your feedback! I've all ready gotten a lot of feedback from Chris, John, Jim, Eric, and many others. Now is your turn! Please read this proposal and send me your comments, suggestions, and concerns. -bw