search for: lpc0_0

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

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

>> Any thoughs? > > I'm now struggling to see how GCC justifies it. What if a different > translation-unit declared those variables in a different order? I also > can't get the same behaviour here, do you have a more complete > command-line? Ah, I see; the translation-unit that does the optimisation needs to have them as a definition (i.e. "= {0}") rather

...ldr r0, .LCPI0_0 add r4, pc, r0 // r4 is the equivalent of ebx in the x86 case. ldr r0, .LCPI0_1 // r0 is the constant that is an immediate in x86. add r0, r0, r4 // that is the add that is folded in x86 ... .LCPI0_0: .long _GLOBAL_OFFSET_TABLE_-(.LPC0_0+8) .LCPI0_1: .long g0(GOTOFF) For ARM, codegen already keeps tracks of offset so it can implement the constant islands, so it should be able to see that the two globals are close enough that offset between them fits an immediate. Nick, will this work on MachO or can ld64 move _g0, _g1 a...