On 16 Dec 2013 16:37, "Michael Hudson-Doyle" <michael.hudson@linaro.org> wrote:
>
> Michael Hudson-Doyle <michael.hudson@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 guess I really mean "between patching the code and writing the relocs out" here.

> 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