From owner-freebsd-current@FreeBSD.ORG Thu Aug 1 13:39:41 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 0148CED; Thu, 1 Aug 2013 13:39:40 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9166E23AB; Thu, 1 Aug 2013 13:39:40 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id r71DdZFS031213; Thu, 1 Aug 2013 16:39:35 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua r71DdZFS031213 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id r71DdZC1031212; Thu, 1 Aug 2013 16:39:35 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 1 Aug 2013 16:39:35 +0300 From: Konstantin Belousov To: Mark Johnston Subject: Re: ldd runs linux programs Message-ID: <20130801133935.GT4972@kib.kiev.ua> References: <20130728193110.GB17514@gpr.nnz-home.ru> <20130728204958.GA32322@dft-labs.eu> <51F5D491.1080803@freebsd.org> <20130729081254.GB32322@dft-labs.eu> <20130729155625.GA2544@charmander> <20130729205449.GA6007@dft-labs.eu> <20130801021231.GA58998@raichu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="sL4HYUAO/BPzex2Y" Content-Disposition: inline In-Reply-To: <20130801021231.GA58998@raichu> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: Gennady Proskurin , Mateusz Guzik , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 13:39:41 -0000 --sL4HYUAO/BPzex2Y Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jul 31, 2013 at 10:12:31PM -0400, Mark Johnston wrote: > On Mon, Jul 29, 2013 at 10:54:49PM +0200, Mateusz Guzik wrote: > > On Mon, Jul 29, 2013 at 11:56:25AM -0400, Mark Johnston wrote: > > > > 127276 suggests running the binary as is (which I don't like) and > > > > achieves this with a hacky way. So if we really want to do this, the > > > > patch should be reworked to detect Linux binaries properly. > > > >=20 > > > > In general we should gain linux_ldd (like linux_kdump) and our ldd > > > > should work only on FreeBSD binaries. The last part is achieved wit= h my > > > > patch. > > > >=20 > > > > markj, are you working on this? > > >=20 > > > Not really; my original fix for this problem was essentially the same= as > > > yours. That is, just change ldd(1) to bail if the OS ABI byte isn't > > > equal to ELFOSABI_FREEBSD. That's the change I have committed in my > > > local tree right now. > > >=20 > > > Then I thought I'd try to get ldd to work properly with Linux binaries > > > as well, but wasn't sure what the right approach should be. As the ab= ove > > > PR suggests, the easy thing to do is to just pass > > > LD_TRACE_LOADED_OBJECTS and not LD_32_TRACE_LOADED_OBJECTS for 32-bit > > > ELF objects if the OS isn't FreeBSD. This feels somewhat hacky to me, > > > but I didn't really see another approach. > > >=20 > > > That said, I think your patch should be committed since it's clearly = an > > > improvement over the current behaviour. I'm willing to test and commit > > > it, and clean up the open PRs. If you could expand on the right way to > > > handle Linux binaries, I'd be willing to implement and commit that to= o. > > > I don't quite understand your reference to linux_kdump though - I have > > > no such program on my laptop running CURRENT, and ktrace+kdump seem to > > > work fine with the Linux binaries under /compat/linux. > > >=20 > >=20 > > Well, there was linux_kdump in ports but it apparently got obsolete as > > necessary support for included in our regular kdump. > >=20 > > So it may make sense to teach our ldd how to deal with Linux binaries > > for consistency, but its unclear for me if this is better than providing > > linux_ldd. Also there is the problem of (not) appending /compat/linux to > > printed paths (for Linux binaries the kernel performs file lookups agai= nst > > /compat/linux first). I'm not that interested in this problem though. :P >=20 > What do you think of the patch below, which just sets both variables in > the compat case? It's somewhat less intrusive than the patch in the PR. > If that's no good then I'll just commit your original patch; I really > just want to fix the fact that the example pipeline in the ldd(1) man > page starts a GTK program (some Adobe Flash thingy to be specific) when > run in /usr/local/bin on my desktop machine. :) >=20 > Thanks, > -Mark >=20 > diff --git a/usr.bin/ldd/ldd.c b/usr.bin/ldd/ldd.c > index 00c8797..71e9c8d 100644 > --- a/usr.bin/ldd/ldd.c > +++ b/usr.bin/ldd/ldd.c > @@ -51,6 +51,7 @@ __FBSDID("$FreeBSD$"); > =20 > #ifdef COMPAT_32BIT > #define LD_ "LD_32_" > +#define LD_COMPAT_ "LD_" > #else > #define LD_ "LD_" > #endif > @@ -211,6 +212,13 @@ main(int argc, char *argv[]) > =20 > /* ld.so magic */ > setenv(LD_ "TRACE_LOADED_OBJECTS", "yes", 1); > +#ifdef COMPAT_32BIT > + /* > + * Set this for the benefit of runtime linkers that don't know > + * we're in compat mode. > + */ > + setenv(LD_COMPAT_ "TRACE_LOADED_OBJECTS", "yes", 1); > +#endif > if (fmt1 !=3D NULL) > setenv(LD_ "TRACE_LOADED_OBJECTS_FMT1", fmt1, 1); > if (fmt2 !=3D NULL) I do not understand this COMPAT_32BIT business in ldd(1). Its only application seems to preventing ldd 32bit binary from amd64 host to work on i386 ? IMO, both LD_TRACE and LD_32_TRACE should be passed unconditionally always. I do not see any harm of doing this. --sL4HYUAO/BPzex2Y Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQIcBAEBAgAGBQJR+mUWAAoJEJDCuSvBvK1BgegQAJML8SLqYCtZol+FvhQ/XI4+ Vbwu5wkl4q1CTG73VwH7cNexWFnATwF2a/4Xt9Yz9OVUxnOGD7Lk1o2Q0RE4Nxhb i8NyOPXpAODFiJFwZGJmKYiWisH2H4f6azjvaprQJjTxCFCFwSOFQkyG+7gTH6L9 3EaJRQoVxZTGgYsEns57sjqvfCKUCnNkyTJ7M5IGNGXWCwBpn+Z12Jz93pUJdefB aWNSRE8eFh85ddTGTAAwsdRyjTFYlwfls22MoYLvBqcArj4YF0G4D5dEYVJItFKH 4YAkoBceFFj/7Rz85w12pT1p4t8R7ZflP0jKXobsxnOmSh6ggjt4mizoXx2ApXBF 5jKOxRNs1ujQPZ9ksGXCgWSQfpjXVpZoJtvv6rpPqFNXoC3iFEp0fgvWd3YwVKtb 2KQw/eAoPLaMIrBhotHtrcWtNpfFlSVAndCa8bJZov8lfeGdnyKb+/MxsxxLNs9+ 4VYyCmIm3aDZM0nO/f7EVEiJz7R6sYANDKNBRRYy99KpbbJIgFL++x392190Y0wR Mmu5J7HU84O/8aTuAvcwM8GKtUpftMV36l6+LQDNHe3L+RBaZ0u5cehQEpPlQY82 fjZ9bZM/+ADzgXLAQ4ADsEf66fIHbRj6hqzWrQr+KmH5vN5x0OvY/scx2KuAed4X vRZeKkQNXjoeArWRvy6S =/pQk -----END PGP SIGNATURE----- --sL4HYUAO/BPzex2Y--