Supporting cross-debugging vmcores in libkvm (Testing needed)

[John Baldwin]

On Wednesday, August 12, 2015 10:50:20 AM John Baldwin wrote:
> On Tuesday, August 04, 2015 10:56:09 AM John Baldwin wrote:
> > Many debuggers (recent gdb and lldb) support cross-architecture debugging 
> > just fine.  My current WIP port of kgdb to gdb7 supports cross-debugging for
> > remote targets already, but I wanted it to also support cross-debugging for
> > vmcores.
> > 
> > The existing libkvm/kgdb code in the tree has some limited support for
> > cross-debugging.  It requires building a custom libkvm (e.g. libkvm-i386.a)
> > and custom kgdb for each target platform.  However, gdb (and lldb) both
> > support multiple targets in a single binary, so I'd like to have a single
> > kgdb binary that can cross-debug anything.
> > 
> > I started hacking on libkvm last weekend and have a prototype that I've used
> > (along with some patches to my kgdb port) to debug an amd64 vmcore on an
> > i386 machine and vice versa.
> >
> > ...
> > 
> > What I'm mostly after is comments on the API, etc.  Once that is settled I
> > will move forward on converting and/or stubbing the other backends (the
> > stub route would be to only support other backends on native systems for
> > now).
> 
> I guess this is closer to a nuclear power plant than a bikeshed judging by the
> feedback.  I have ported the rest of the MD backends and verified that the
> updated libkvm passes a universe build (including various static assertions
> for the duplicated constants in other backends).  What I have not done is any
> runtime testing and I would like to ask for help with that now.  In particular
> I need someone to test that kgdb and/or ps works against a native core dump
> on all platforms other than amd64 and i386.  Note that some of the trickiness
> is that the backends now have to make runtime decisions for things that were
> previously compile-time decisions.  The biggest one affected by this is the
> MIPS backend as that backend handles three ABIs (mipso32, mipsn32, and mipsn64).
> I believe I have the handling for that correct (mips[on]32 use 32-bit KSEGs
> where as mipsn64 uses the extended segments and compat32 KSEGS, and mipso32
> uses 32-bit PTEs and mipsn32/n64 both use 64-bit PTEs) (plus both endians
> for both in theory).  The ARM backend also handles both endians (in theory).
> 
> Another wrinkle is that sparc64 uses its own dump format instead of writing
> out an ELF file.  I had to convert the header structures to use fixed-width
> types to be cross-friendly.  It would be good to ensure that a new libkvm
> can read a vmcore from an old kernel and vice versa to make sure my conversion
> is correct (I added an explicit padding field that I believe was implicit
> before).
> 
> The code is currently available for review in phabric at
> https://reviews.freebsd.org/D3341
> 
> To test, you can run 'arc patch D3341' in a clean tree to apply the patch.

I've just rebased this to port aarch64's minidump support.  I just need people
willing and able to test on non-x86.  Testing with the in-tree kgdb using an
updated libkvm would be sufficient.

-- 
John Baldwin