svn commit: r325728 - head/lib/libkvm
jhb at FreeBSD.org
Tue Feb 5 17:14:59 UTC 2019
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 at 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
> 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.
More information about the svn-src-all