Roland McGrath wrote:
>
> 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.
I can always attempt. Whether I succeed or not depends on my
understanding.
I'd like to work on it because I believe I can figure it out. If I'm
wrong
and I can't, nothing's harmed. :)
> 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.
Yes. I saw this afternoon how to walk through memory with vm_region and
I think I have this part of it in hand. Basic idea as I understand it
is:
addr = 0;
while (!vm_region(&addr, &size..)) {
/* elf dumping code goes here */
addr+= size;
}
> 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.
The register set seems to be available from thread_get_state(). That
took
a little looking to figure out, but I think I'm ok here now too. The
idea is to stash the threads' register info in segments called
'.regs[n]'
where [n] is the thread ID if I'm not mistaken. GDB doesn't seem to
need
a WHOLE LOT of work if I stick to a fairly standard core file format
like elf.
> 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.
I agree that a standalone program is the best way to get myself
bootstrapped
in this case.
I have pulled some of the structure together here, but it is currently
using
the 'elf.h' structures directly and calculating offsets. When I figured
out that libbfd would do most of this for me, I thought I'd rewrite it
using
that, so I'll spend a little time understanding bfd's API.
Thanks for all your help.
Jonathan S. Arney
Software Engineer
(602) - 589 - 6654
[EMAIL PROTECTED]
------------------------------------------------------------------------
_______________________________________________
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
