lkml.org 
[lkml]   [2003]   [Apr]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [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/

\
 
 \ /
  Last update: 2005-03-22 13:35    [W:0.047 / U:0.820 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site