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