Jeremy Fitzhardinge wrote:
> Zachary Amsden wrote:
>
>> Invoke black magic to relocate the VDSO even when COMPAT_VDSO is enabled
>> by fixing up the ELF object.
>>
>>
>
> So does it actually work? Can you boot the broken distros with this in
> place?
>
Well testing that is not so fun. I installed SUSE Pro 9.0, and strings
on ld.so contains the magic at_sysinfo assert! But it doesn't install
TLS libraries, so I'll have to install them by hand.
In works - in theory. Look, a puppy!
Scratchbox is rumored to produce the fabled assertion even on modern
distros by installing its own toolchain which includes the dreaded glibc.
> Using sections is wrong; you should be going through the phdrs, and
> looking for PT_DYNAMIC for relocation.
>
Will do.
> Does anyone expect the symbolic info to be correct? It might be better
> to just stomp it so nobody gets any ideas.
>
> On the other hand, we don't want to break compatibility with anything...
>
I'm playing safe. Binary identical relocation to 0xffffe000 was my goal.
>> + } else if (strcmp(secstrings+sechdrs[i].sh_name, ".dynamic") == 0) {
>> + Elf32_Dyn *dyn = (void *)hdr + sechdrs[i].sh_offset;
>> + int tag;
>> + while ((tag = (++dyn)->d_tag) != DT_NULL)
>>
>>
>
> Um, no.
>
Walk based on size instead?
>> + } else if (strcmp(secstrings+sechdrs[i].sh_name, ".useless") == 0) {
>> + /* This is demonic; see vsyscall.lds.S; it puts the
>> + * .got in a section named .useless */
>> + uint32_t *got = (void *)hdr + sechdrs[i].sh_offset;
>> + *got += VDSO_HIGH_BASE;
>> + }
>>
>>
>
> This won't get relocated with one of the other relocations? It's in the
> text phdr.
>
Hmm, I can try that. Thanks for the suggestions / fixes.
Zach
_______________________________________________
Virtualization mailing list
Virtualization@xxxxxxxxxxxxxx
https://lists.osdl.org/mailman/listinfo/virtualization
