From owner-freebsd-ia64@FreeBSD.ORG Wed Mar 10 20:25:13 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 47D94106566C; Wed, 10 Mar 2010 20:25:13 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id AE2138FC20; Wed, 10 Mar 2010 20:25:12 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id o2AKOw3R062702 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Mar 2010 22:24:58 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id o2AKOwO9094686; Wed, 10 Mar 2010 22:24:58 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id o2AKOw7l094685; Wed, 10 Mar 2010 22:24:58 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 10 Mar 2010 22:24:58 +0200 From: Kostik Belousov To: Nathan Whitehorn Message-ID: <20100310202458.GG2489@deviant.kiev.zoral.com.ua> References: <4B971CA3.9090301@freebsd.org> <201003100810.10696.jhb@freebsd.org> <4B97AF13.5040104@freebsd.org> <201003101043.23275.jhb@freebsd.org> <4B97C0FC.4020209@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="+U0EQ97FbU8QddnY" Content-Disposition: inline In-Reply-To: <4B97C0FC.4020209@freebsd.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua 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 20:25:13 -0000 --+U0EQ97FbU8QddnY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Mar 10, 2010 at 09:55:40AM -0600, Nathan Whitehorn wrote: > John Baldwin wrote: > >On Wednesday 10 March 2010 9:39:15 am Nathan Whitehorn wrote: > > =20 > >>John Baldwin wrote: > >> =20 > >>>On Tuesday 09 March 2010 11:14:27 pm Nathan Whitehorn wrote: > >>> =20 > >>> =20 > >>>>The patch at=20 > >>>>http://people.freebsd.org/~nwhitehorn/compat_freebsd32.diff=20 > >>>>(pre-generated freebsd32 syscalls stuff is included, which will be do= ne=20 > >>>>in two steps on commit) provides groundwork for supporting 32-bit=20 > >>>>compatibility for 64-bit MIPS and PowerPC systems. It has been tested= =20 > >>>>on amd64 and powerpc64, and compile-tested on ia64. There are two mai= n=20 > >>>>parts to the patch: > >>>> > >>>>1) COMPAT_IA32 is renamed COMPAT_FREEBSD32, in analogy to=20 > >>>>COMPAT_LINUX32, etc. This requires updating kernel configurations, bu= t=20 > >>>>is less painful than filling machine-independent bits of the kernel= =20 > >>>>with #if defined(COMPAT_IA32) || defined(COMPAT_PPC32) ||=20 > >>>>defined(COMPAT_MIPS32) || ..., and is no less descriptive than the ol= d=20 > >>>>name. > >>>> > >>>>2) Modifications to the freebsd32 compat layer to support big-endian= =20 > >>>>architectures. > >>>> > >>>>I would appreciate any comments, bugs, or test results on ia64. > >>>> =20 > >>>> =20 > >>>This doesn't look right for non-x86 32-bit ABIs: > >>> > >>>Index: sys/kern/imgact_elf.c > >>>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >>>--- sys/kern/imgact_elf.c (revision 204681) > >>>+++ sys/kern/imgact_elf.c (working copy) > >>>@@ -1439,7 +1439,7 @@ > >>> ehdr->e_ident[EI_ABIVERSION] =3D 0; > >>> ehdr->e_ident[EI_PAD] =3D 0; > >>> ehdr->e_type =3D ET_CORE; > >>>-#if defined(COMPAT_IA32) && __ELF_WORD_SIZE =3D=3D 32 > >>>+#if defined(COMPAT_FREEBSD32) && __ELF_WORD_SIZE =3D=3D 32 > >>> ehdr->e_machine =3D EM_386; > >>> #else > >>> ehdr->e_machine =3D ELF_ARCH; > >>> =20 > >>> =20 > >>Good catch! Such are the dangers of sed. How about defining an=20 > >>ELF_ARCH32 in machine/elf.h for this case? > >> =20 > > > >Yes, that sounds good. > > > > =20 > >>>It would be nice to eliminate having includes in MI cod= e=20 > >>>by instead including those headers in appropriate headers in=20 > >>>. For example, we could change on amd64 an= d=20 > >>>ia64 to include these headers, perhaps under an #ifdef COMPAT_FREEBSD3= 2. > >>> > >>>Hmm, actually, I'm quite convinced now that for ia64 a= nd=20 > >>>amd64 should include in the #ifdef _KERNEL=20 > >>>section to avoid polluting those includes in MI code. I'm not sure wh= at=20 > >>>the various includes are for, but fixing ia32_reg.h=20 > >>>would be a good first step. It would make your diffs smaller I think. > >>> =20 > >>> =20 > >>This is how it works on powerpc64. I didn't modify amd64 and ia64 in=20 > >>order to avoid making too many changes, but I think you're right that= =20 > >>this is a good idea. I'll add that to the patch when fixing the EM_386= =20 > >>bit you pointed out above. > >> =20 > > > >Ok, thanks. > > > > =20 > I've updated the patch to incorporate these two changes, at=20 > http://people.freebsd.org/~nwhitehorn/compat_freebsd32_2.diff. Due to=20 > recursive inclusion issues with sys/procfs.h, it also moves prstatus32=20 > and friends to compat/freebsd32/freebsd32.h from ia32_reg.h. They are=20 > MI, and seems like a more appropriate place for them anyway. First chunk for the sys_generic.c about ibits/obits looks like a bug fix ? If yes, it probably would make sense to commit it separately to be able to MFC it. The same note about chunks that remove #include , if possible ? --+U0EQ97FbU8QddnY Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkuYABkACgkQC3+MBN1Mb4i05gCg1vQsucGORz01W+nvgVl0pTTg zQ4AoILaoHaEBCSDcNkMAfqWeEbhTv2g =80ld -----END PGP SIGNATURE----- --+U0EQ97FbU8QddnY--