The proc server is not really much involved. You need to understand the structure of the system and what Mach tasks and threads are about in some detail before attempting to work on this.
Certainly writing an ELF core file is the right thing to do. How to store the memory is clear, and that part of the file format is just the same as for Linux and other systems that use ELF core files. You can look at the `vminfo' program (utils/vminfo.c) to see how to use vm_region to examine the address space of a task, and then you use vm_read to get the data. The rest of the information about register state and so on is a little less clear. How we will store it is clear: in ELF notes as other systems do. But how many notes and what formats to use for them is up to us. We need to choose those note formats, and modify gdb to understand them. Mark Kettenis is the authority in the Hurd native gdb port, and I will tend to defer to him on what these formats should be. I suggest that you start out by just doing the memory dump and not worrying about the rest at all (no notes). Rather than hacking on the crash server directly, it will be easiest to debug this in a little standalone program that just uses pid2task to get the task port of a process, suspends it, and dumps its memory as an ELF core file (i.e. a minimal "gcore"). I might get around to whipping up the basic memory-dumping code soon, and then you could see how it's done and debug the code for me. _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
