Michael Hudson-Doyle <michael.hud...@linaro.org> writes: > Will Newton <will.new...@linaro.org> writes: > >> On 16 December 2013 03:36, Michael Hudson-Doyle >> <michael.hud...@linaro.org> wrote: >>> Michael Hudson-Doyle <michael.hud...@linaro.org> writes: >>> >>>> Aaah, you might be onto something there. I built myself a cross gcc-4.8 >>>> today and it appeared to compile things correctly (I didn't actually get >>>> to run it, but the objdump poking looked right) and I got a bit worried >>>> that this was all down to some cosmic ray / corruption when I first >>>> compiled it. But, the scripts I cargo culted just use compile binutils >>>> from git tip, so if the bug is in binutils... >>> >>> So I still don't know what's going on, exactly, but I have a debug build >>> of binutils now and some clues. It still only happens on real hardware, >>> not cross compiling on my laptop, but I think I have an idea as to why. >>> This might be complete crack, but anyway. >>> >>> I think it's to do with the order of things within the GOT. >>> >>> When I cross compile, sort the relocations by address, then count up the >>> number of relocations of each type, it looks like this: >>> >>> $ objdump -C -R build/linux2/*/mongo/base/counter_test | LC_ALL=C sort | >>> cut -d' ' -f 2 | uniq -c >>> 4 >>> 496 R_AARCH64_GLOB_DAT >>> 1 R_AARCH64_TLS_TPREL64 >>> 103 R_AARCH64_GLOB_DAT >>> 305 R_AARCH64_JUMP_SLOT >>> 12 R_AARCH64_COPY >>> 1 RELOCATION >>> 2 >>> >>> In this case, the code and the relocation agree on where the thread >>> local variable is. >>> >>> When I compile natively, it looks like this: >>> >>> (t-mwhudson)ubuntu@arm64:~/src/mongo$ objdump -C -R >>> build/linux2/*/mongo/base/counter_test | LC_ALL=C sort | cut -d' ' -f 2 | >>> uniq -c >>> 4 >>> 295 R_AARCH64_JUMP_SLOT >>> 496 R_AARCH64_GLOB_DAT >>> 1 R_AARCH64_TLS_TPREL64 >>> 104 R_AARCH64_GLOB_DAT >>> 12 R_AARCH64_COPY >>> 1 RELOCATION >>> 2 >>> >>> And the code and the relocation disagree on where the thread local >>> variable is -- by 298 * sizeof(void*). Which is almost (but I admit, >>> not exactly) the number of JUMP_SLOTs that are, in this case, before the >>> TLS variable in the GOT. When I compiled in a different way, there were >>> only 160 JUMP_SLOTs before the TLS reloc, and the code and relocation >>> disagreed by 163 slots. >>> >>> So is it possible somehow that the GOT has these JUMP_SLOTs inserted >>> into it after the relocation for the TLS has been written out? I don't >>> really see how but maybe this rings a bell... >> >> Indeed it does. ;-) >> >> A similar issue was caused by commit >> 692e2b8bcdd8325ebfbe1daace87100d53d15ad6 (which adds ifunc support to >> the aarch64 ld backend) but was intended to be fixed by the rework of >> the same code in 1419bbe5712af8a43f1d63feb32687649563426d. However I >> was never actually able to reproduce the failure case (I saw binaries >> that were broken so I know it could happen) so the fix was somewhat >> speculative. Hence I am very interested in finding a reproducible case >> where this GOT entry misordering happens! > > I'm possibly doing something wrong, but I've tried to try compiling the > suspect binary with both binutils git tip and the commit before > 692e2b8bc but both had the problem. So I guess it's something else, or > I wasn't testing what I thought I was testing.
Argh, I wasn't testing what I thought I was testing... trying again. Cheers, mwh _______________________________________________ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
