Re: core file writing

[Jon Arney]

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
jarney1@cox.net
------------------------------------------------------------------------