From owner-freebsd-current@FreeBSD.ORG Thu Aug 1 02:12:39 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 A88A18C3; Thu, 1 Aug 2013 02:12:39 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-qc0-x22b.google.com (mail-qc0-x22b.google.com [IPv6:2607:f8b0:400d:c01::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5067A2105; Thu, 1 Aug 2013 02:12:39 +0000 (UTC) Received: by mail-qc0-f171.google.com with SMTP id n10so806884qcw.30 for ; Wed, 31 Jul 2013 19:12:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=yqUjrqfFrmNdlKOADiixEKkKmnfzmtIePQ4jFPm/lf8=; b=O5k7Mla9ss6JBqelt06QFMngrFvVYWnooQLkcZpON3zdW+aBIqvw34u5Obab8FRh6Q b8X4FA6c7UjW9YHV6+QexPgEmDRrCA7fW2PhJ1Z31pxmchvVBlmBRPEn99T12Hum3l/K oA2An7u7Y/QEIsWI+sJUsqYiW18grvebk3TKaXgqKVqGxmvm6u2rWxnIzJ7ndzgzfRQG UMEpiiZJ/2KrlMomPFWid1JqV/7qMda1xu2qCh8JDN54nO17dzN+N2N8/zUC1CTsB8g5 R1GL9w0NtnB7nyFLG9PlT/J2g2A/0oq/tgdZ2wP6NdOmOB5aJYbx3Cp2bREIYGTIwxFn 1omg== X-Received: by 10.49.16.197 with SMTP id i5mr86427644qed.58.1375323158394; Wed, 31 Jul 2013 19:12:38 -0700 (PDT) Received: from raichu (24-212-218-13.cable.teksavvy.com. [24.212.218.13]) by mx.google.com with ESMTPSA id l15sm1835281qav.13.2013.07.31.19.12.36 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 31 Jul 2013 19:12:37 -0700 (PDT) Sender: Mark Johnston Date: Wed, 31 Jul 2013 22:12:31 -0400 From: Mark Johnston To: Mateusz Guzik , Julian Elischer , Gennady Proskurin , freebsd-current@freebsd.org Subject: Re: ldd runs linux programs Message-ID: <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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130729205449.GA6007@dft-labs.eu> User-Agent: Mutt/1.5.21 (2010-09-15) 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 02:12:39 -0000 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. > > > > > > In general we should gain linux_ldd (like linux_kdump) and our ldd > > > should work only on FreeBSD binaries. The last part is achieved with my > > > patch. > > > > > > markj, are you working on this? > > > > 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. > > > > 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 above > > 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. > > > > 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 too. > > 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. > > > > Well, there was linux_kdump in ports but it apparently got obsolete as > necessary support for included in our regular kdump. > > 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 against > /compat/linux first). I'm not that interested in this problem though. :P 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. :) Thanks, -Mark 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$"); #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[]) /* 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 != NULL) setenv(LD_ "TRACE_LOADED_OBJECTS_FMT1", fmt1, 1); if (fmt2 != NULL)