Date: Wed, 12 Aug 2015 10:50:20 -0700 From: John Baldwin <jhb@freebsd.org> To: freebsd-arch@freebsd.org Subject: Re: Supporting cross-debugging vmcores in libkvm (Testing needed) Message-ID: <5166205.rtMjEmhvmo@ralph.baldwin.cx> In-Reply-To: <3121152.ujdxFEovO3@ralph.baldwin.cx> References: <3121152.ujdxFEovO3@ralph.baldwin.cx>
next in thread | previous in thread | raw e-mail | index | archive | help
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. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5166205.rtMjEmhvmo>