svn commit: r325728 - head/lib/libkvm
brooks at freebsd.org
Tue Feb 5 17:22:30 UTC 2019
On Tue, Feb 05, 2019 at 09:14:46AM -0800, John Baldwin wrote:
> 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.
IIRC, you created kvaddr_t first and I co-opted it for the kernel after
finding a namespace collision when I merged the kvaddr_t from CheriBSD.
Using kvm_ types seems like a good idea for the reaons you hilight.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 455 bytes
Desc: not available
More information about the svn-src-all