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