Messages in this thread | | | From | David Mosberger <> | Date | Fri, 25 Apr 2003 09:21:46 -0700 | Subject | Re: [PATCH] i386 vsyscall DSO implementation |
| |
I like this. Even better would be if all platforms could do the same. I'm definitely interested in doing something similar for ia64 (the getunwind() syscall was always just a stop-gap solution).
I assume that these kernel ELF images would then show up in dl_iterate_phdr()?
To complete the picture, it would be nice if the kernel ELF images were mappable files (either in /sysfs or /proc) and would show up in /proc/PID/maps. That way, a distributed application such as a remote debugger could gain access to the kernel unwind tables on a remote machine (assuming you have a remote filesystem).
--david
>>>>> On Thu, 24 Apr 2003 19:10:50 -0700, Roland McGrath <roland@redhat.com> said:
>> We already embed a cpio archive into __initdata space. What >> about putting the images in there, and either copying the data >> out of initramfs, or, directly referencing the pages that store >> each image?
Roland> It doesn't matter to me, but I don't see the benefit to Roland> doing that. It's rather unlike what initramfs is used for Roland> now and would need a bunch of extra code to accomplish Roland> something very simple.
Roland> The DSO images are not stored page-aligned and padded in the Roland> kernel image, so the pages can't be used directly. Storing Roland> them that way would use more space in the kernel image on Roland> disk, and then you'd want to free initdata page containing Roland> the unused one. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |