Re: [PATCH] aarch64: simplify the DT_AARCH64_VARIANT_PCS handling code

[Szabolcs Nagy <Szabolcs dot Nagy at arm dot com>]

On 11/07/2019 10:07, Szabolcs Nagy wrote:
> On 10/07/2019 20:46, Florian Weimer wrote:
>> * Szabolcs Nagy:
>>
>>> On 09/07/2019 13:55, Szabolcs Nagy wrote:
>>>> Remove unnecessary variant_pcs field: the dynamic tag can be checked
>>>> directly.
>>>>
>>>> I'll commit this tomorrow unless there are comments.
>>>> Then backport it with the variant pcs support to release branches
>>>> https://sourceware.org/ml/libc-alpha/2019-05/msg00523.html
>>>
>>> i was about to back port this but i wonder if
>>> glibc has policy that a release branch cannot
>>> change libc internal abi between dynamic linker
>>> and lib*.so to allow reliable updates?
>>>
>>> this patch changes the size of map->l_info array.
>>
>> The usual issue involves changing the size of _rtld_global and
>> _rtld_global_ro.
>>
>> I don't know to what extent libc and libdl access link maps directly,
>> without going through ld.so.  I don't recall seeing anything like
>> that, but that doesn't mean much.
> 
> i'll try to do some analysis, but e.g. l_tls_* is after l_info
> in struct link_map and i'd expect those to be accessed by
> libpthreads and ld.so as well.
> 

i checked what happens with old ld.so but new lib*.so and
libc.so can call

  EXTERN void (*_dl_rtld_lock_recursive) (void *);

member of the rtld_global struct in ld.so during a
__GI__dl_addr(ptmalloc_init,...) call, but there is a

  EXTERN struct link_map _dl_rtld_map;

member before, so inconsistent link_map size across
libc and ld.so breaks this.

i suspect rtld_global._dl_tls_* and link_map->l_tls*
access would be broken too if execution could get there.