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 <b...@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 _______________________________________________ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
