------- Comment #20 from iains at gcc dot gnu dot org 2010-05-16 15:15 ------- (In reply to comment #19) > Subject: Re: r159371 breaks bootstrap on > x86_64-apple-darwin10 > > > ------- Comment #17 from iains at gcc dot gnu dot org 2010-05-16 13:51 > > ------- > > (In reply to comment #16) > > > leaving off the eh and debug stuff.... look at >>>>>> > > > > > > .text > > > __ZN12_GLOBAL__N_110get_globalEv: > > > LFB100: > > > pushq %rbp > > > LCFI0: > > > movq %rsp, %rbp > > > LCFI1: > > > >>>>>> reference a variable relative to the instruction pointer???????? > > > >>>>>> is this intended?? seems doomed to > > > >>>>>> fail at some point .... > > > leaq > > > ___emutls_v._ZZN12_GLOBAL__N_110get_globalEvE6global(%rip), > > > %rdi > > > > well, clearly, it's intended - non-emutls code does the same thing (when > > compiled m64). > > However, the point remains that a 32bit offset is going to fail to reach > > variables as soon as the total space occupied > 4Gb > > > > it seems maybe we have a code-gen problem ? > > Well, you know that emults will be bound withtin the same DSO, so you are > safe. > This is small PIC model.
hmmm.. I don't quite understand this.. the original ld error was: ld: codegen problem, can't use rel32 to external symbol ___emutls_v._ZZN12_GLOBAL__N_110get_globalEvE6global in ___cxa_get_globals_fast is the loader not entitled to place .data and .text wherever it likes in the 64bit address space? ... in any event, potentially, further apart than can be reached by a +/- 31 bits. .. what happens when the data size passes 2Gb? (having said that - I agree that it doesn't make a lot of sense to see this failure when building libstdc++ ...) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44146
