From owner-freebsd-ia64@FreeBSD.ORG Wed Mar 10 14:39:24 2010 Return-Path: Delivered-To: freebsd-ia64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 84090106566B; Wed, 10 Mar 2010 14:39:24 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from argol.doit.wisc.edu (argol.doit.wisc.edu [144.92.197.212]) by mx1.freebsd.org (Postfix) with ESMTP id 531BC8FC1A; Wed, 10 Mar 2010 14:39:24 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from avs-daemon.smtpauth3.wiscmail.wisc.edu by smtpauth3.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) id <0KZ20001EM1L4600@smtpauth3.wiscmail.wisc.edu>; Wed, 10 Mar 2010 08:39:21 -0600 (CST) Received: from comporellon.tachypleus.net (adsl-76-233-145-10.dsl.mdsnwi.sbcglobal.net [76.233.145.10]) by smtpauth3.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) with ESMTPSA id <0KZ200K8BM1FYT40@smtpauth3.wiscmail.wisc.edu>; Wed, 10 Mar 2010 08:39:16 -0600 (CST) Date: Wed, 10 Mar 2010 08:39:15 -0600 From: Nathan Whitehorn In-reply-to: <201003100810.10696.jhb@freebsd.org> To: John Baldwin Message-id: <4B97AF13.5040104@freebsd.org> X-Spam-Report: AuthenticatedSender=yes, SenderIP=76.233.145.10 X-Spam-PmxInfo: Server=avs-12, Version=5.5.5.374460, Antispam-Engine: 2.7.1.369594, Antispam-Data: 2010.3.10.143049, SenderIP=76.233.145.10 References: <4B971CA3.9090301@freebsd.org> <201003100810.10696.jhb@freebsd.org> User-Agent: Thunderbird 2.0.0.23 (X11/20100206) Cc: freebsd-emulation@freebsd.org, freebsd-amd64@freebsd.org, freebsd-ia64@freebsd.org Subject: Re: Request for review/comments: 32-bit compat for non-x86 architectures X-BeenThere: freebsd-ia64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the IA-64 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Mar 2010 14:39:24 -0000 John Baldwin wrote: > On Tuesday 09 March 2010 11:14:27 pm Nathan Whitehorn wrote: > >> The patch at http://people.freebsd.org/~nwhitehorn/compat_freebsd32.diff >> (pre-generated freebsd32 syscalls stuff is included, which will be done >> in two steps on commit) provides groundwork for supporting 32-bit >> compatibility for 64-bit MIPS and PowerPC systems. It has been tested on >> amd64 and powerpc64, and compile-tested on ia64. There are two main >> parts to the patch: >> >> 1) COMPAT_IA32 is renamed COMPAT_FREEBSD32, in analogy to >> COMPAT_LINUX32, etc. This requires updating kernel configurations, but >> is less painful than filling machine-independent bits of the kernel with >> #if defined(COMPAT_IA32) || defined(COMPAT_PPC32) || >> defined(COMPAT_MIPS32) || ..., and is no less descriptive than the old name. >> >> 2) Modifications to the freebsd32 compat layer to support big-endian >> architectures. >> >> I would appreciate any comments, bugs, or test results on ia64. >> > > This doesn't look right for non-x86 32-bit ABIs: > > Index: sys/kern/imgact_elf.c > =================================================================== > --- sys/kern/imgact_elf.c (revision 204681) > +++ sys/kern/imgact_elf.c (working copy) > @@ -1439,7 +1439,7 @@ > ehdr->e_ident[EI_ABIVERSION] = 0; > ehdr->e_ident[EI_PAD] = 0; > ehdr->e_type = ET_CORE; > -#if defined(COMPAT_IA32) && __ELF_WORD_SIZE == 32 > +#if defined(COMPAT_FREEBSD32) && __ELF_WORD_SIZE == 32 > ehdr->e_machine = EM_386; > #else > ehdr->e_machine = ELF_ARCH; > Good catch! Such are the dangers of sed. How about defining an ELF_ARCH32 in machine/elf.h for this case? > It would be nice to eliminate having includes in MI code by > instead including those headers in appropriate headers in . For > example, we could change on amd64 and ia64 to include these > headers, perhaps under an #ifdef COMPAT_FREEBSD32. > > Hmm, actually, I'm quite convinced now that for ia64 and amd64 > should include in the #ifdef _KERNEL section to avoid > polluting those includes in MI code. I'm not sure what the various > includes are for, but fixing ia32_reg.h would be a good first > step. It would make your diffs smaller I think. > This is how it works on powerpc64. I didn't modify amd64 and ia64 in order to avoid making too many changes, but I think you're right that this is a good idea. I'll add that to the patch when fixing the EM_386 bit you pointed out above. > The rest of the diff looks fine to me. > Thanks for the comments! -Nathan