svn commit: r325728 - head/lib/libkvm

[John Baldwin]

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
>> 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