Will Newton will.newton@linaro.org writes:
On 12 December 2013 23:14, Michael Hudson-Doyle michael.hudson@linaro.org wrote:
Will Newton will.newton@linaro.org writes:
On 12 December 2013 21:59, Michael Hudson-Doyle michael.hudson@linaro.org wrote:
Will Newton will.newton@linaro.org writes:
[sniiiip]
I would guess that 0x64c000 is the base of the GOT and 776 is the offset into it (but I could be wrong). objdump -h will give you the layout of the sections, objdump -R will dump the relocations.
So I get this:
$ objdump -h build/linux2/normal/mongo/base/counter_test | grep got --context=2 23 .dynamic 00000220 000000000064b160 000000000064b160 0023b160 2**3 CONTENTS, ALLOC, LOAD, DATA 24 .got 00001c78 000000000064b380 000000000064b380 0023b380 2**3 CONTENTS, ALLOC, LOAD, DATA 25 .data 00000130 000000000064d000 000000000064d000 0023d000 2**4
And objdump -C -R gives this: http://paste.ubuntu.com/6563640/
This would seem to be the relevant entry:
000000000064ccb8 R_AARCH64_TLS_TPREL64 mongo::_threadOstreamCache
But I don't know what the offset means here and how it relates to the 776 in "ldr x0, [x0,#776]". 0x64c000 + 776 is 0x64c308 which is
000000000064c308 R_AARCH64_GLOB_DAT vtable for boost::program_options::typed_value<unsigned int, char>
This looks wrong.
Yeah, it does. Also poking around at 0x64c308 shows something that looks very much like a vtable for a class called typed_value...
which is just random, but I don't know if that's a valid thing to be looking at :-) That said, if we examine the memory at 0x64ccb8 and interpret it as an offset against tpidr_el0 things *seem* to make sense:
(gdb) x 0x64ccb8 0x64ccb8: 0x00000010 (gdb) x/g $x1 + 0x10 0x7fb7ff7700: 0x0000000000000000
The correct value for this tls pointer at this point in time _is_ in fact NULL, but obviously this could happen just by chance :-)
Still, looks a bit like a toolchain bug to me. This is with g++ 4.8 from trusty fwiw.
I would be inclined to agree. Is there a simple way to reproduce the build?
Ha. No, I've only seen this when compiling all of mongodb, which takes a pretty long time on hw. I'll certainly let you know if I can come up with something smaller. I'll also try with 4.9.
Small is good, but we do have access to hardware so at least it won't be days waiting for the model. ;-)
(although I don't think I will have time to look at it until the new year)
No worries, a bug on launchpad.net/linaro-gcc is the right way to track this properly?
Yeah I think so, although I think it will actually be a binutils bug.
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...
Cheers, mwh