From owner-freebsd-amd64@FreeBSD.ORG Mon Sep 15 19:28:07 2008 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 511F01065671 for ; Mon, 15 Sep 2008 19:28:07 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id ADD558FC20 for ; Mon, 15 Sep 2008 19:28:06 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [IPv6:::1]) (authenticated bits=0) by server.baldwin.cx (8.14.2/8.14.2) with ESMTP id m8FJRe5X082601; Mon, 15 Sep 2008 15:27:41 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: Dominic Fandrey Date: Mon, 15 Sep 2008 10:47:12 -0400 User-Agent: KMail/1.9.7 References: <200809111640.m8BGe4PX012172@freefall.freebsd.org> <200809111637.54863.jhb@freebsd.org> <48CD20CB.3040706@bsdforen.de> In-Reply-To: <48CD20CB.3040706@bsdforen.de> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200809151047.12396.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [IPv6:::1]); Mon, 15 Sep 2008 15:27:41 -0400 (EDT) X-Virus-Scanned: ClamAV 0.93.1/8249/Mon Sep 15 12:31:36 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.1 required=4.2 tests=BAYES_00, DATE_IN_PAST_03_06, NO_RELAYS autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: freebsd-amd64@freebsd.org Subject: Re: amd64/127276: ldd invokes linux yes X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2008 19:28:07 -0000 On Sunday 14 September 2008 10:33:47 am Dominic Fandrey wrote: > John Baldwin wrote: > > FreeBSD binaries from various releases have been branded in different ways. I > > would consider it more of a user error to run ldd on a Linux binary. :) You > > could maybe add a "IMPLEMENTATION NOTES" section to the manpage that explains > > how it works and why it will execute any binary using a different runtime > > linker. > > > > Well, documenting it is much better than the current state. Though in my > opinion it doesn't matter to the user how it works, but what one expects the > program to do. And the current behaviour is not what I expected. > > Would you instead accept a patch from me that does a compatibility check and > bails out if the binary does not use the FreeBSD linker? It can be hard to determine that. What happens is that each ELF binary includes a path to its interpreter (i.e. the runtime linker). For FreeBSD binaries this can be either /usr/libexec/ld-elf.so.1 or /libexec/ld-elf.so.1 or the a.out paths (/usr/libexec/ld.so.1 I think). In the kernel, ABI modules hook into exec and when they see a binary they can handle, they can choose to overwrite the interpreter path to point it to somewhere else (e.g. the Linux ABI uses a path under /compat/linux instead, and the 'freebsd32' ABI on amd64 uses /libexec/ld-elf32.so.1). Any ELF binary that uses one of the two ld-elf.so.1 (or ld-elf32.so.1) paths will use the FreeBSD runtime linker, regardless of which "OS" the binary is targeted for. You could maybe hardcode the list of interpreter strings to check for, but that wouldn't be completely foolproof. You could have an ABI that is fine with using the FreeBSD linker even though its native "OS" uses a different interpreter path (though that is unlikely). In that case the kernel module would be rewriting the interpreter path to be the FreeBSD ld-elf, but ldd would have no clue. > The "IMPLEMENTATION NOTES" would still be nice to have, though. It's always > a nice read to get an idea on how something works. And I find code much > easier to decipher if I already know how it's supposed to do something. At > least much easier than the opposite way, trying to glimpse how something > works from the code. > > Regards > -- John Baldwin