Date: Sat, 27 Feb 2010 10:06:22 -0800 From: Juli Mallett <jmallett@FreeBSD.org> To: Alexander Kabaev <kabaev@gmail.com> Cc: src-committers@freebsd.org, svn-src-user@freebsd.org Subject: Re: svn commit: r204391 - in user/jmallett/octeon/sys: ddb mips/mips ufs/ffs Message-ID: <eaa228be1002271006k689a3de2k95c724c401aca5fb@mail.gmail.com> In-Reply-To: <20100227100134.52899b18@kan.dnsalias.net> References: <201002270338.o1R3cd04040906@svn.freebsd.org> <20100227100134.52899b18@kan.dnsalias.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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. *: 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. Juli.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?eaa228be1002271006k689a3de2k95c724c401aca5fb>