On 12 December 2013 23:14, Michael Hudson-Doyle <[email protected]> wrote: > Will Newton <[email protected]> writes: > >> On 12 December 2013 21:59, Michael Hudson-Doyle >> <[email protected]> wrote: >>> Will Newton <[email protected]> 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. -- Will Newton Toolchain Working Group, Linaro _______________________________________________ linaro-toolchain mailing list [email protected] http://lists.linaro.org/mailman/listinfo/linaro-toolchain
