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...
Cheers,
mwh
_______________________________________________
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain
