Re: [PATCH] Implement "info proc mappings" for NetBSD

[John Baldwin <jhb@FreeBSD.org>]

On 3/20/20 11:50 AM, Tom Tromey wrote:
>>>>>> "Kamil" == Kamil Rytarowski <n54@gmx.com> writes:
> 
> Kamil> I see. I prefer to keep this called obfd, as it matches the FreeBSD code
> Kamil> more closely. If we want to rename it, we shall do it also in FreeBSD.
> 
> Well, that FreeBSD code is wrong too...

I looked, and I think that name was just inherited.  The callback argument commonly
passed to this function is in fact the bfd for a core file being generated (e.g.
from gcore_memory_sections) and other functions like objfile_find_memory_regions()
still use 'obfd' here.  I think it's perfectly reasonable to rename the
variable.  The exec target uses 'data' which it gained when it became a C++ class
instead of setting to_find_memory_regions to objfile_find_memory_regions directly.

>>> What if they stop matching?
> 
> Kamil> Not a concern.
> 
> Kamil> If that will ever change, it will be patched, same as the other
> Kamil> existing NetBSD support.
> 
> How will cross debugging to different versions work in this situation?

From FreeBSD's perspective, we probably won't ever change these bitfields as our
struct kinfo_vmentry is a public structure that we make ABI promises about that
is supposed to be the "public" version of internal kernel structures.  I suspect
NetBSD is following a similar model.

FWIW, I did the code in the tdep file to support core file debugging and cross
debugging (which works).  I think the Linux tdep code also does info proc
in the tdep file for similar reasons.  In the case of Linux, linux-tdep.c
handles core dumps, while procfs.c appears to handle native processes.

The formatting of using manual tables, etc. for info proc is also something the
Linux and procfs backends do.  It might indeed be much cleaner to use ui-out
(and probably more friendly to mi if we did so?)

-- 
John Baldwin