On Fri, Oct 27, 2017 at 07:48:43PM +0200, Michal Meloun wrote: > But there is something what's still missing me. > The rescue binary is statically linked, so whole program have only one > TLS section and full TLS layout is determined by linker. > The problematic structure, tsd_tls, is first one in TLS section group: > > readelf -a /usr/obj/usr/src/rescue/rescue/rescue | grep TLS > 518961: 0000000000000000 2880 TLS GLOBAL DEFAULT 9 __je_tsd_tls > and > > objdump -d -j .tdata /usr/obj/usr/src/rescue/rescue/rescue > 00a832b0 <__je_tsd_tls+0xa832b0>: > a832b0: 00000005 > > but disassembled code expect it at TLS ptr + 0x8 (for code without > JEMALLOC_ALIGNED) or at TLS ptr + 0x10 (for code with JEMALLOC_ALIGNED) > > [without JEMALLOC_ALIGNED] > 7c4d90: e59f0014 ldr r0, [pc, #20] ; 7c4dac > <tsd_get+0x80> > 7c4d94: e58d0004 str r0, [sp, #4] > 7c4d98: eb031d14 bl 88c1f0 <__aeabi_read_tp> > 7c4d9c: e59dc004 ldr ip, [sp, #4] > 7c4da0: e080000c add r0, r0, ip > 7c4da4: e1a0d00b mov sp, fp > 7c4da8: e8bd8800 pop {fp, pc} > 7c4dac: 00000008 .word 0x00000008 [0x10 for code > with JEMALLOC_ALIGNED] > > so someone other allocates at least one byte from start of TLS and > linker is aware about this. But again, .data is first member of TLS > and tsd_tls is first of .tdata and the 0x5 is value of first member of > tsd_tls structure (.state = tsd_state_uninitialized). > > So who consumes the first bytes in TLS ????
Hack the makefile to pass the -M option to linker, like -Wl,-M >/some/path/file.map. The file.map provides the data about sections assembly. _______________________________________________ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"