Re: x86-64 prelink support for TLS dialect gnu2

[Steven Newbury <steven dot newbury at googlemail dot com>]

On 06/11/2018, Steven Newbury <steven.newbury@googlemail.com> wrote:
> On 06/11/2018, Steven Newbury <steven.newbury@googlemail.com> wrote:
>
>> From the reverted ARM prelink patch it's clear the magic is in the
>> section guarded
>> by RESOLVE_CONFLICT_FIND_MAP.  The x86_64 code already handles several
>> different cases of R_X86_64_TLSDESC in that switch so I still don't
>> understand how it falls through to _dl_reloc_bad_type rather than just
>> ignoring the prelink suppliied address.  Most of the ARM patch
>> consists of asserts presumably because the code wasn't fully trusted.
>>
> Okay, I've applied the attached patch inserting the code removed from
> the ARM dl-machine.h into the x86_64 code handling R_X86_64_TLSDESC.
> I still get the same error:
>
> error while loading shared libraries: unexpected reloc type 0x24
>
> Which can only be coming from _dl_reloc_bad_type() after it's fallen
> through the switch in elf_machine_rela() or the if-else block in
> elf_machine_lazy_rel(), both of which have should not fall through
> since R_X86_64_TLSDESC is reloc type 0x24 and it is, or should be
> handled!
>
Despite staring at the code for hours I didn't see the case was
guarded by an #ifdef block.  The patch I last attached doesn't compile
when the code is moved outside without the resolver being changed
since _dl_tlsdesc_lazy_resolver isnt present for x86-64.  Even then
the map->l_info[VALIDX (DT_GNU_PRELINKED)] != NULL doesn't seem to
work.  Mind you it no longer fails to run the binary, whether it's
actually using the prelinked value is another matter..?