Date: Thu, 1 Aug 2013 16:39:35 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: Mark Johnston <markj@freebsd.org> Cc: Gennady Proskurin <gprspb@mail.ru>, Mateusz Guzik <mjguzik@gmail.com>, freebsd-current@freebsd.org Subject: Re: ldd runs linux programs Message-ID: <20130801133935.GT4972@kib.kiev.ua> In-Reply-To: <20130801021231.GA58998@raichu> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
--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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130801133935.GT4972>