This is the mail archive of the
mailing list for the glibc project.
Re: x86-64 prelink support for TLS dialect gnu2
On 06/11/2018, Steven Newbury <firstname.lastname@example.org> wrote:
> On 06/11/2018, Steven Newbury <email@example.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
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..?