Re: re-enabling debugging of 32 bit processes with 64 bit debugger

[Andrew Cagney <andrew.cagney%gmail.com@localhost>]

On Sun, 30 Jun 2019 at 10:28, Jason Thorpe <thorpej%me.com@localhost> wrote:
>
>
> > On Jun 30, 2019, at 6:46 AM, Andrew Cagney <andrew.cagney%gmail.com@localhost> wrote:
> >
> > Things started to go down hill when the debugger developers decided
> > that rooting around in the process to extract the memory map was "a
> > good idea". After all, it too is likely been corrupted by the crashing
> > program.
> >
> > There's /proc/PID/maps, there should be a PTRACE equivalent and it
> > should also be dumped into the core file.
>
> Certainly, the ELF core files dumped by NetBSD have a PT_LOAD section for each VM map entry, so the memory map information is already there.

Right (with debugger magic filling in the missing but listed read-only
segments).

>  Now, for mapped files, it doesn't record the path name like you get with /proc/PID/maps, but that's something that could be fixed by having one or more additional PT_NOTE sections where the note contains a PT_LOAD index to file name mapping (with the path string being contained in the note).

What ever the format it might as well be consistent between  /proc,
ptrace() and core dumps, and should accommodate variable length paths
(unlike the current core file structure).  Spewing /proc/pid/maps
(actually, much of /proc/pid) as one or more notes into core file is a
good starting point (and one known to work).   Other formats are also
valid.

(I thought 9 had forked)

> -- thorpej
>