Re: core file writing

[Roland McGrath]

Great stuff!  Thanks again for working on this.

I checked in the fix for that stupid libc bug (d'oh!).

As to gdb, did you test the gdb "gcore" command?  Your patch didn't include
any changes to the gnu_find_memory_regions function, but you also didn't
say that it works.  Since that part of the code works independent of the
new note formats, I would like to get it folded into gdb asap.

The i386-specific code will go into i386gnu-nat.c, not gnu-nat.c (but don't
worry about that right now).

I'm still trying to iron out what note formats I think we should use.  I
think I am going to follow the model used by recent Solaris systems rather
than the one used by Linux, because it seems to fit better with having
multiple threads.  By using those existing note type codes and defining
those type names in <sys/procfs.h> we can avoid modifying the gdb elfcore
code at all (as you did by matching the Linux types) and also get proper
handling of multiple threads (which gdb doesn't grok for Linux, since Linux
doesn't write them).

I've just checked into hurd/exec/elfcore.c some code to write the NT_PSINFO
note, which is where it deals with talking to the proc server (replacing
your code that makes the NT_PRPSINFO note).  For the data_t parameters, it
never makes much sense to malloc an initial buffer, and your use of free
after the RPC calls is wrong.  The way data_t out parameters work is that
the client supplies a pointer and length to a buffer that can be used if
convenient, but the RPC might get out-of-line memory or might allocate
pages to copy into.  In either case, you can't call free on the pointer you
get back, you must use munmap.  For the usual practice is to pass the
address of a small stack buffer, and call munmap if the returned pointer is
not the address of the original buffer.  It's also always fine to just set
the initial pointer and size to zero, and unconditionally call munmap on
the returned pointer and size.  As usual, my code compiles but is untested
and so might have some stupid bugs.

I'm still working on the sys/procfs.h type definitions, but I think I will
be adding this file to the hurd package when it's a little more together.

Following the Solaris model (actually, following gdb's elfcore.c, the code
that reads these notes), we will have an NT_PSINFO note (that part I've
written already), which gdb uses for the program arguments; an NT_PSTATUS
note, which gdb uses for the PID (don't ask me why it doesn't get it from
the NT_PSINFO note too, it's there!); and for each thread an NT_LWPSTATUS
note, which gdb uses for the thread registers.

I am still vacillating on how to encode the thread registers in the
NT_LWPSTATUS notes.