From owner-freebsd-emulation@FreeBSD.ORG Mon Jul 14 10:23:34 2008 Return-Path: Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 84AA61065675 for ; Mon, 14 Jul 2008 10:23:34 +0000 (UTC) (envelope-from freebsd-emulation@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 10EE48FC1E for ; Mon, 14 Jul 2008 10:23:33 +0000 (UTC) (envelope-from freebsd-emulation@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1KILDQ-0000x9-0o for freebsd-emulation@freebsd.org; Mon, 14 Jul 2008 10:23:32 +0000 Received: from 81.210.247.130 ([81.210.247.130]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 14 Jul 2008 10:23:32 +0000 Received: from saper by 81.210.247.130 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 14 Jul 2008 10:23:32 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-emulation@freebsd.org From: Marcin Cieslak Date: Mon, 14 Jul 2008 12:23:16 +0200 Lines: 74 Message-ID: <487B2914.9020409@system.pl> References: <20080711115436.GZ17123@deviant.kiev.zoral.com.ua> <4877BAB8.1030804@system.pl> <20080714104352.14951o38351fjnpc@webmail.leidinger.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-ripemd160; protocol="application/pgp-signature"; boundary="------------enig4277687B93FF810F9F019DAC" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 81.210.247.130 User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.8.1.13) Gecko/20080405 SeaMonkey/1.1.9 Mnenhy/0.7.5.0 In-Reply-To: <20080714104352.14951o38351fjnpc@webmail.leidinger.net> X-Enigmail-Version: 0.95.6 Sender: news Subject: Re: linux emulation: Preliminary support for more auxvec's [patch] X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jul 2008 10:23:34 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig4277687B93FF810F9F019DAC Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: quoted-printable Alexander Leidinger wrote: > Quoting Marcin Cieslak (from Fri, 11 Jul 2008 21:55:3= 6=20 > +0200): >=20 >> The patch is here: >> >> http://akson.sgh.waw.pl/~saper/FreeBSD/linux/auxvec.diff >=20 >=20 > -#define AT_COUNT 15 /* Count of defined aux entry types. */ > +#define AT_COUNT 18 /* Count of defined aux entry types. */ > ---snip--- >=20 > I would expect that count is 24, not 18. But what happens if we increas= e=20 > it to 24, is it expected to have some valid data by some automatism=20 > based upon AT_COUNT then? What's in 18-22? Well, the count is the count - it's number of slots in the table. It is=20 used for the allocation of the structure space. As Kostik Belousov pointed, rtld uses this (incorrectly) in=20 libexec/rtld-elf/rtld.c in _rtld() an array of AT_COUNT elements is=20 created and only items with values (0..AT_COUNT) are included in the tabl= e. This should be probably be changed to something in similar to lib/libc/gen/tls.c (see _init_tls() at the very end). Solaris sys/auxv.h comments explain the 18-22 shift (Linux collided with PPC ABI values): http://cvs.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/= sys/auxv.h You can also here that Solaris defines quite large AT_* values, so an=20 approach taken by rtld is not practical in the long term. I think in the long term (upstream, not in the linuxolator) we should=20 allow ELF stack fixup routine to dynamically allocate user stack and get = rid of AT_COUNT completely. I guess this could be done by extending=20 (struct sysentvec *) and changing the code around 457 of kern_exec.c to=20 separate "copy out strings" and "separate stack base" functions. This work-in-progress patch=20 (http://people.freebsd.org/~kib/misc/rtld-origin.1.patch) also requires=20 some allocation on the user stack. --Marcin --------------enig4277687B93FF810F9F019DAC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQCVAwUBSHspGT2W2v2wY27ZAQNsQgP+NWw6xaaJPYHU7bO+jBBcngM2N7alYgHH xuwI8PBZtYzI85doxbTJngUGCzxi/jkVtnPmkbuAU8/MOwu9a2f6dHvWHxxQVgeW YG7zWDqLatOorc0m9yxlk6nZY7Rh/gQeJzJMlBi+OGPa+mt0GBZHE0QygoH8ATS7 0C+/b6GYjGY= =636Q -----END PGP SIGNATURE----- --------------enig4277687B93FF810F9F019DAC--