Date: Fri, 27 Nov 2015 11:04:23 -0800 From: John Baldwin <jhb@freebsd.org> To: src-committers@freebsd.org Cc: svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r291406 - in head: . gnu/usr.bin/gdb/kgdb lib/libkvm rescue/rescue share/mk sys/sparc64/include Message-ID: <2898094.TQmcuznC5g@ralph.baldwin.cx> In-Reply-To: <201511271858.tARIwQOt030605@repo.freebsd.org> References: <201511271858.tARIwQOt030605@repo.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Friday, November 27, 2015 06:58:26 PM John Baldwin wrote: > Author: jhb > Date: Fri Nov 27 18:58:26 2015 > New Revision: 291406 > URL: https://svnweb.freebsd.org/changeset/base/291406 > > Log: > Add support to libkvm for reading vmcores from other architectures. > - Add a kvaddr_type to represent kernel virtual addresses instead of > unsigned long. > - Add a struct kvm_nlist which is a stripped down version of struct nlist > that uses kvaddr_t for n_value. > - Add a kvm_native() routine that returns true if an open kvm descriptor > is for a native kernel and memory image. > - Add a kvm_open2() function similar to kvm_openfiles(). It drops the > unused 'swapfile' argument and adds a new function pointer argument for > a symbol resolving function. Native kernels still use _fdnlist() from > libc to resolve symbols if a resolver function is not supplied, but cross > kernels require a resolver. > - Add a kvm_nlist2() function similar to kvm_nlist() except that it uses > struct kvm_nlist instead of struct nlist. > - Add a kvm_read2() function similar to kvm_read() except that it uses > kvaddr_t instead of unsigned long for the kernel virtual address. > - Add a new kvm_arch switch of routines needed by a vmcore backend. > Each backend is responsible for implementing kvm_read2() for a given > vmcore format. > - Use libelf to read headers from ELF kernels and cores (except for > powerpc cores). > - Add internal helper routines for the common page offset hash table used > by the minidump backends. > - Port all of the existing kvm backends to implement a kvm_arch switch and > to be cross-friendly by using private constants instead of ones that > vary by platform (e.g. PAGE_SIZE). Static assertions are present when > a given backend is compiled natively to ensure the private constants > match the real ones. > - Enable all of the existing vmcore backends on all platforms. This means > that libkvm on any platform should be able to perform KVA translation > and read data from a vmcore of any platform. > > Tested on: amd64, i386, sparc64 (marius) > Differential Revision: https://reviews.freebsd.org/D3341 emaste@ reviewed some pieces of this but not all I believe. I have not fully tested the in-tree cross-kgdb support though I believe it should build in the new world order without requiring one to build a cross libkvm. That is, you should just need to build the cross-debugger now using the stock libkvm. The kgdb patches in devel/gdb in ports already support this new interface, though it is only enabled at compile time if compiled on a world with the new libkvm. Currently the amd64 and i386 backends in kgdb in ports support cross-vmcore debugging, so you should be able to debug an amd64 or i386 vmcore on any platform where devel/gdb runs. As more platforms are added to devel/gdb they should all support cross-debugging (so, for example, once arm is added to devel/gdb and the kgdb bits in devel/gdb, one would be able to debug an arm vmcore on an amd64 host). Another fun trick would be to add some build glue to make libkvm buildable on other OS's (e.g. on OS X) so that gdb (or lldb) could be built on OS X and use the portable libkvm to debug a kernel vmcore from a non-FreeBSD host. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2898094.TQmcuznC5g>