svn commit: r204391 - in user/jmallett/octeon/sys: ddb mips/mips ufs/ffs

M. Warner Losh imp at bsdimp.com
Sat Feb 27 21:10:41 UTC 2010


In message: <eaa228be1002271006k689a3de2k95c724c401aca5fb at mail.gmail.com>
            Juli Mallett <jmallett at FreeBSD.org> writes:
: On Sat, Feb 27, 2010 at 07:01, Alexander Kabaev <kabaev at gmail.com> wrote:
: > On Sat, 27 Feb 2010 03:38:38 +0000 (UTC)
: > Juli Mallett <jmallett at FreeBSD.org> wrote:
: >
: >> Make ddb commands take an address as an intptr_t, not a db_expr_t.
: >> It is possible to have 32-bit pointers and 64-bit registers and thus
: >> a 64-bit db_expr_t.
: >>
: >
: > This is a step back, imho. Can you redefine db_expr_t to be of
: > appropriate size instead?
: 
: I'm not thrilled with it and wouldn't commit it to the main tree.
: db_expr_t is register/expression sized, though, so for an n32 kernel*
: it is right for it to be bigger than a pointer.  Being able to view
: and modify only the low 32-bits of registers just because pointers are
: 32 bits is demonstrably incorrect.  I think using db_addr_t makes some
: sense, assuming there are no sign-extension problems from its being
: unsigned.

n32 is an odd-ball ABI.  the pointers are stored as 32-bit, but the
registers are 64-bit and through the magic of signed extension, things
work....

: *: Whether having an n32 kernel makes sense would be a reasonable
: question to ask.  An n32 loader and an n64 kernel (assuming support
: for running all kinds of binaries in userland) should be good enough
: to cover the case where having an n64 kernel is undesirable but an n32
: kernel is desirable, which is where the bootloader is incapable of
: loading ELF64 properly (we could also support o64, but there are bugs
: with o64 in the toolchain that we'd have to fix.)  I'm spending effort
: on an n32 kernel right now because I was having more trouble getting a
: bootable n64 kernel together than an n32 one.

I'm not sure that an n32 kernel makes sense, in the long run.  o64
doesn't make sense.  n64 is really the only kernel that makes sense.
It gets rid of lots of kludges and doesn't introduce its own set...
o32 kernel for the mips32 ABIs is correct (since it doesn't have
64-bit registers).

Warner


More information about the svn-src-user mailing list