From owner-svn-src-user@FreeBSD.ORG Sat Feb 27 18:37:43 2010 Return-Path: Delivered-To: svn-src-user@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7F6DF106566C for ; Sat, 27 Feb 2010 18:37:43 +0000 (UTC) (envelope-from juli@clockworksquid.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.159]) by mx1.freebsd.org (Postfix) with ESMTP id 20E818FC12 for ; Sat, 27 Feb 2010 18:37:42 +0000 (UTC) Received: by fg-out-1718.google.com with SMTP id 19so826446fgg.13 for ; Sat, 27 Feb 2010 10:37:34 -0800 (PST) MIME-Version: 1.0 Sender: juli@clockworksquid.com Received: by 10.102.196.33 with SMTP id t33mr1738201muf.2.1267294002089; Sat, 27 Feb 2010 10:06:42 -0800 (PST) In-Reply-To: <20100227100134.52899b18@kan.dnsalias.net> References: <201002270338.o1R3cd04040906@svn.freebsd.org> <20100227100134.52899b18@kan.dnsalias.net> From: Juli Mallett Date: Sat, 27 Feb 2010 10:06:22 -0800 X-Google-Sender-Auth: cd7dc7fa9663becb Message-ID: To: Alexander Kabaev Content-Type: text/plain; charset=ISO-8859-1 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 X-BeenThere: svn-src-user@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the experimental " user" src tree" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Feb 2010 18:37:43 -0000 On Sat, Feb 27, 2010 at 07:01, Alexander Kabaev wrote: > On Sat, 27 Feb 2010 03:38:38 +0000 (UTC) > Juli Mallett 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.