Date: Tue, 5 Feb 2019 09:14:46 -0800 From: John Baldwin <jhb@FreeBSD.org> To: Bruce Evans <brde@optusnet.com.au>, Ed Maste <emaste@freebsd.org> Cc: Will Andrews <will@freebsd.org>, src-committers <src-committers@freebsd.org>, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r325728 - head/lib/libkvm Message-ID: <b5bb8301-9793-a37b-0721-6ce70a1fd4de@FreeBSD.org> In-Reply-To: <20190206024025.X3175@besplex.bde.org> References: <201711112330.vABNUwXC077395@repo.freebsd.org> <CAPyFy2BwNGHkMjj2rG5N5S=7E8N=9jfAUBki1L8eCY3kMeM8fw@mail.gmail.com> <20190205202145.A1080@besplex.bde.org> <CAPyFy2C%2BZ0aOGUBbgpLZ8sJbaN2YhEbR1YkV9Ya7POTSsbLqGQ@mail.gmail.com> <20190206024025.X3175@besplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2/5/19 8:25 AM, Bruce Evans wrote: > On Tue, 5 Feb 2019, Ed Maste wrote: > >> On Tue, 5 Feb 2019 at 05:17, Bruce Evans <brde@optusnet.com.au> wrote: >>> >>> On Mon, 4 Feb 2019, Ed Maste wrote: >>>> This should probably be uin64_t to support cross-debugging cores from >>>> 64-bit machines on 32-bit hosts; also for i386 PAE. Or, on IRC jhb >>>> suggested we introduce a kpaddr_t typedef akin to kvaddr_t. >>> >>> The correct type is vm_paddr_t or maybe a kvm wrapper of this. >> >> That precludes cross-arch and cross-size use of kvm_walk_pages; kvm >> supports this use (see kvm_read2) so it should be a 64-bit kvm >> wrapper. > > kvm or system? kvaddr_t is system and the corresponding physical address > type should probably be system too. It only needs to exist for libkvm. I want to make a 'portable' libkvm that can be built on non-FreeBSD OS's such as OS X, etc. That is the last thing needed to let kgdb run on non-FreeBSD OS's to cross-debug crash dumps. For that you would want self-contained types I think such as kvm_vaddr_t and kvm_paddr_t. I guess I just reused kvaddr_t because it already existed, but having dedicated types in kvm.h is probably better long term. > Signed kp_offset seems wrong. Apart from it not reaching the top of 64- > bit address spaces, adding unsigned kp_len to it gives an unsigned type. kp_offset is the file offset in the vmcore file so that you can directly use it with pread() or lseek(). In that case, I think off_t is the right type. Similarly, the 'len' should stay as size_t since it is intended to be used as the argument to read()/pread() or a size passed to malloc(), etc. I don't think vm_ooffset_t is appropriate as it is 1) non-portable and 2) not suitable for userspace APIs. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?b5bb8301-9793-a37b-0721-6ce70a1fd4de>