Date: Sat, 27 Feb 2010 14:06:17 -0700 (MST) From: "M. Warner Losh" <imp@bsdimp.com> To: jmallett@FreeBSD.org Cc: src-committers@FreeBSD.org, kabaev@gmail.com, svn-src-user@FreeBSD.org Subject: Re: svn commit: r204391 - in user/jmallett/octeon/sys: ddb mips/mips ufs/ffs Message-ID: <20100227.140617.295937982770209745.imp@bsdimp.com> In-Reply-To: <eaa228be1002271006k689a3de2k95c724c401aca5fb@mail.gmail.com> References: <201002270338.o1R3cd04040906@svn.freebsd.org> <20100227100134.52899b18@kan.dnsalias.net> <eaa228be1002271006k689a3de2k95c724c401aca5fb@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <eaa228be1002271006k689a3de2k95c724c401aca5fb@mail.gmail.com>
Juli Mallett <jmallett@FreeBSD.org> writes:
: On Sat, Feb 27, 2010 at 07:01, Alexander Kabaev <kabaev@gmail.com> wrote:
: > On Sat, 27 Feb 2010 03:38:38 +0000 (UTC)
: > Juli Mallett <jmallett@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100227.140617.295937982770209745.imp>