From owner-freebsd-amd64@FreeBSD.ORG Mon Sep 15 19:52:36 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 05BBE106564A; Mon, 15 Sep 2008 19:52:36 +0000 (UTC) (envelope-from kamikaze@bsdforen.de) Received: from mail.bsdforen.de (bsdforen.de [212.204.60.79]) by mx1.freebsd.org (Postfix) with ESMTP id B42378FC12; Mon, 15 Sep 2008 19:52:35 +0000 (UTC) (envelope-from kamikaze@bsdforen.de) Received: from mobileKamikaze.norad (unknown [92.116.180.83]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.bsdforen.de (Postfix) with ESMTP id 213BD8A0129; Mon, 15 Sep 2008 21:52:12 +0200 (CEST) Message-ID: <48CEBCE4.5070204@bsdforen.de> Date: Mon, 15 Sep 2008 21:52:04 +0200 From: Dominic Fandrey User-Agent: Thunderbird 2.0.0.16 (X11/20080810) MIME-Version: 1.0 To: John Baldwin References: <200809111640.m8BGe4PX012172@freefall.freebsd.org> <200809111637.54863.jhb@freebsd.org> <48CD20CB.3040706@bsdforen.de> <200809151047.12396.jhb@freebsd.org> In-Reply-To: <200809151047.12396.jhb@freebsd.org> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 15 Sep 2008 20:09:55 +0000 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:52:36 -0000 John Baldwin wrote: > 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. > I wanted to look into the file and readelf tools to check how they do it. I'm using readelf to avoid calling ldd when inappropriate and I think it's reliable, so there aught to be a way. I'm kinda stressed, but I'm going to look into it in a couple of weeks. If it doesn't pay off. Well, I'm all for the implementation notes.