svn commit: r324938 - head/contrib/jemalloc/include/jemalloc/internal

[Konstantin Belousov]

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.