Date: Fri, 11 Jul 2008 23:38:47 +0200 From: Marcin Cieslak <saper@system.pl> To: freebsd-emulation@freebsd.org Subject: Re: linux emulation: Preliminary support for more auxvec's [patch] Message-ID: <4877D2E7.9020408@system.pl> In-Reply-To: <20080711201450.GB17123@deviant.kiev.zoral.com.ua> References: <g57h1u$5od$1@ger.gmane.org> <20080711115436.GZ17123@deviant.kiev.zoral.com.ua> <4877BAB8.1030804@system.pl> <20080711201450.GB17123@deviant.kiev.zoral.com.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig3BBBBF8E7698244C8C5474AC Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: quoted-printable Kostik Belousov wrote: > Do you know of any situation where we _must_ have those new auxvec you > implemented ? No, I learned about them today when I analyzed my auxvec fingerprint=20 from the real amd64 and i386 Linux boxes. >=20 >> >> http://akson.sgh.waw.pl/~saper/FreeBSD/linux/auxvec.diff > I only briefly looked over it. >=20 > I suggest that the new AT_COUNT requires more thinking. Look at the > src/libexec/rtld-elf/rtld.c, _rtld(), at line 338, where the auxvec is > digested by FreeBSD dynamic linker. It seems to be harmless, but at > least this is inconsistent. May be, AT_LINUX_PLATFORM etc defines > would make more sense. machine/elf.h will get updated with installworld (or make install in=20 includes) and rtld should get be recompiled with this. I did this and it works fine as it worked. The impact of this is=20 limited, since all the auxvec's rtld need are stored early. I don't think the AT_COUNT things is correct. >=20 > Do you actually need imgp->machine member ? It seems that it is used > only inside linux_copyout_strings ? No, it's referenced in elf_linux_fixup - that's the reason I need it. >> This was made against 7-STABLE, but there no major differences in=20 >> -current. It is also trivial to port to 64-bit amd64 emulation. > Hmm, what are you referencing there ? I know only about one mostly > stalled effort. Well, anyway the logic is pretty platform-independent and one needs to=20 be careful about pointer sizes (AT_PLATFORM) and such. Newly introduced linux_get_machine should take care of the 64-bit case. If we are going to support dynamic switching between 32 and 64 bit code=20 this will need to be dynamic as well ("x86_64" vs "i686"). I have my doubts about the linux_times() function in linux_misc.c, it tries to convert the clock tick to the FreeBSD value. Maybe it's no=20 longer necessary. If this is a problem, we can hardcode value "100" as being returned. --Marcin --------------enig3BBBBF8E7698244C8C5474AC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQCVAwUBSHfS6j2W2v2wY27ZAQMjHwP+NliobJxuVqw3NvAI7cc0yhbi7qaM5Ybm FAypt4puLpYYzkmKg6qAeXCWrsig/BtJ5SCKTbcPhGrVXrU4jlWf0+ZidTYGy2RM GP/91WNHyoOG3kYMU+cw0rggXFlfyuHI8gPHaqhlwkZwoYz21T5NPKYKFnt22t0l dQfenvwZ4nw= =xRtz -----END PGP SIGNATURE----- --------------enig3BBBBF8E7698244C8C5474AC--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4877D2E7.9020408>