On Fri, May 04, 2007 at 09:24:05PM -0700, Jeremy Fitzhardinge wrote: > > Indeed, I haven't seen that. For ET_DYN executables, it could be done a > > thing like load_addr+elf_ppnt->p_vaddr (in the function that creates the > > auxv, as ity has access to the elf header), and for ET_EXEC do what I > > propose. I think this is trivial to do. I'll do it as soon as I come back > > in front of my machine. > > > > I don't think you need to special-case it. You can compute the offset > between the linked address and the load address (first > PT_LOAD[0]->p_vaddr - load_addr) and use that to offset all the other > addresses. Indeed. And it has the advantage to work for prelinked objects. (but I have to understand anyway how does the kernel handles prelinked (or not) pie executables) > > > > I don't understand. Yes it is what it is supposed to be, and the kernel > > is supposed to give the vaddr of the phdr table to the interpreter and > > not load addr + offset of phdr in file, which is sometimes wrong. > > > > How can it be wrong? Does the PT_PHDR point to a different array of > Phdr entries? No, of course, but in my case I wanted to build an executable with a modified rpath. I had to add a new PT_LOAD segment. To do so, as the program header is generally located at the very beginning of the executable, I had to copy it to the end, and so the address where it was loaded was completely different. The load address was typically 0x08048000, and the phdr location was 0x0804a570. But the kernel gave to the ld.so in the auxv the addr 0x08048570 for the phdr. And it provoked a segfault because of the .bss which was between the segments. (and even if there was no .bss, it would have worked only by chance because the segments could all fit in a page of 4kb) Quentin - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
