Supporting cross-debugging vmcores in libkvm

John Baldwin jhb at freebsd.org
Wed Aug 5 00:09:43 UTC 2015


On Tuesday, August 04, 2015 12:00:59 PM John-Mark Gurney wrote:
> John Baldwin wrote this message on Tue, Aug 04, 2015 at 10:56 -0700:
> > 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.
> 
> Have you looked at the work the my GSoC student, Daniel Lovasko, is
> doing:
> https://wiki.freebsd.org/SummerOfCode2015/TypeAwareKernelVirtualMemoryAccess
> 
> This uses libctf to completely abstract out the accessing of data
> in libkvm so that it can be used w/ any arch as long as you have ctf
> data...  This means you could use netstat on amd64 on an armeb vmcore
> w/o issues...
> 
> It does look like some of this is still useful, but want to make sure
> that we aren't reproducing tons of work...
> 
> For example, he's working on procstat right now:
> https://github.com/lovasko/taprocstat

That doesn't seem to address the need of how you parse the actual vmcore
file itself to resolve a virtual address to a location in the vmcore file.
(e.g. on "plain" dumps on i386 this means walking the page tables whereas
for minidumps it means parsing a special set of PTEs and bitmap at the
start of the file).

To be clear, all that my work enables is doing a kvm_read() of a foreign
vmcore.  All the logic to decide how many bytes to read and at what
address (and then decoding those appropriately) happens in the debugger
(gdb/lldb, etc.).  The project here seems to be using CTF instead of
dwarf to do the sort of things the debugger does when you 'p *foo', but
you still need a way to find the 'foo' in the vmcore file.

-- 
John Baldwin


More information about the freebsd-arch mailing list