Will Newton <will.new...@linaro.org> writes: > On 12 December 2013 21:59, Michael Hudson-Doyle > <michael.hud...@linaro.org> wrote: >> Will Newton <will.new...@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. > (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? Cheers, mwh _______________________________________________ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
