Re: aarch64 TLS optimizations?

[Szabolcs Nagy <Szabolcs.Nagy@arm.com>]

On 20/05/2019 16:59, Tom Horsley wrote:
> On Mon, 20 May 2019 15:43:53 +0000
> Szabolcs Nagy wrote:
> 
>> you can verify that 0x152000 + 3608 == 0x152e18 is
>> indeed a GOT entry (falls into .got) and there is a
>>
>> 0000000000152e18 R_AARCH64_TLS_TPREL64  *ABS*+0x0000000000000010
> 
> There are a couple of other TLS variables in malloc, and I
> suspect this is one of them, where it is actually looking
> at tcache_shutting_down (verified with debug info and disassembly),
> it is simply using the tpidr_el0 value still laying around
> in the register from the 1st TLS reference and loading
> tcache_shutting_down from an offset which appears for all the
> world to simply be hard coded, no GOT reference involved.
> 
> I suppose at some point I'll be forced to understand how to build
> glibc from the ubuntu source package so I can see exactly
> what options and ifdefs are used and check the relocations in
> the malloc.o file from before it is incorporated with libc.so

in my build of malloc.os in glibc in the symtab i see

    84: 0000000000000000     0 TLS     LOCAL  DEFAULT   10 .LANCHOR3
    85: 0000000000000000     8 TLS     LOCAL  DEFAULT   10 thread_arena
    86: 0000000000000008     8 TLS     LOCAL  DEFAULT   10 tcache
    87: 0000000000000010     1 TLS     LOCAL  DEFAULT   10 tcache_shutting_down

and the R_*_TLSIE_* relocs are for .LANCHOR3 + 0,
so there will be one GOT entry for the 3 objects
and you should see

tp + got_value + (0 or 8 or 16)

address computation to access the 3 objects.

e.g. in __malloc_arena_thread_freeres i see

    4e04:	d53bd056 	mrs	x22, tpidr_el0
    4e08:	90000015 	adrp	x21, 0 <_dl_tunable_set_mmap_threshold>	4e08: R_AARCH64_TLSIE_ADR_GOTTPREL_PAGE21	.LANCHOR3
    4e0c:	f94002b5 	ldr	x21, [x21]	4e0c: R_AARCH64_TLSIE_LD64_GOTTPREL_LO12_NC	.LANCHOR3
    4e10:	a90153f3 	stp	x19, x20, [sp, #16]
    4e14:	8b1502c0 	add	x0, x22, x21   // x0 = tp + got_value
    4e18:	f9400414 	ldr	x20, [x0, #8]  // read from tcache
    4e1c:	f9001bf7 	str	x23, [sp, #48]
    4e20:	b4000234 	cbz	x20, 4e64 <__malloc_arena_thread_freeres+0x6c>
    4e24:	52800021 	mov	w1, #0x1                   	// #1
    4e28:	91010293 	add	x19, x20, #0x40
    4e2c:	91090297 	add	x23, x20, #0x240
    4e30:	f900041f 	str	xzr, [x0, #8] // write to tcache
    4e34:	39004001 	strb	w1, [x0, #16] // write to tchace_shutting_down

i doubt ubuntu changed this, but if the offset is
a fixed const in the binary that means they moved
that variable into the glibc internal pthread struct
(which is at a fixed offset from tp).