From owner-freebsd-current@FreeBSD.ORG Sat Jul 1 14:08:09 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A30BD16A407 for ; Sat, 1 Jul 2006 14:08:09 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from pi.codefab.com (pi.codefab.com [199.103.21.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3BED243D45 for ; Sat, 1 Jul 2006 14:08:09 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from localhost (localhost [127.0.0.1]) by pi.codefab.com (Postfix) with ESMTP id 972365E6D; Sat, 1 Jul 2006 10:08:08 -0400 (EDT) X-Virus-Scanned: amavisd-new at codefab.com Received: from pi.codefab.com ([127.0.0.1]) by localhost (pi.codefab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lvOeuQbr7zoS; Sat, 1 Jul 2006 10:08:06 -0400 (EDT) Received: from [192.168.1.251] (pool-68-160-201-170.ny325.east.verizon.net [68.160.201.170]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pi.codefab.com (Postfix) with ESMTP id 1C8235C2C; Sat, 1 Jul 2006 10:08:06 -0400 (EDT) Message-ID: <44A681C3.3000309@mac.com> Date: Sat, 01 Jul 2006 10:08:03 -0400 From: Chuck Swiger User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Kostik Belousov References: <200607010009.09231@aldan> <20060701122005.GC37822@deviant.kiev.zoral.com.ua> In-Reply-To: <20060701122005.GC37822@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: current@freebsd.org, Mikhail Teterin Subject: Re: weird limitation on the system's binutils X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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: Sat, 01 Jul 2006 14:08:09 -0000 Kostik Belousov wrote: > On Sat, Jul 01, 2006 at 12:09:08AM -0400, Mikhail Teterin wrote: [ ... ] >> I'm wondering, why the bfd and related bits and pieces of binutils are built >> to support only the architecture(s), that can natively run on the system? >> >> Why can't I use gdb or objdump on FreeBSD/i386 to analyze a core file, or a >> binary from another FreeBSD or even from a non-FreeBSD system? >> >> The tools themselves support that. The sources (bfd-vectors) for all other >> supported architectures are part of the tree (under contrib/). So, why not >> build them? > > AFAIK, binutils can only support one architecture per invocation of > configuration scripts. I.e., you cannot have one gas binary that would > provide both i386-elf and hppa-som targets. Correct me, if I'm wrong. You may be right for ELF, but there exist other binary formats like Mach-O which support "multiple-architecture binaries", and at one point, NeXT's version of the GNU compiler & binutils toolchain supported cross-compilation and debugging between any of x86, m68k, sparcv8 & hppa. PowerPC has obviously been added since, and I suspect that the HP/PA and maybe the SPARC have bit-rotted. For example, at one company the developers commonly ran on original NeXT hardware or the Canon Object.Station 41's, and would spawn remote builds for their native platform to an HP 735 which was used as a fast compile-server. When you wanted to do a final build for production or testing, you'd compile for all four architectures, rather than just yours. In order to get to this level, however, you needed to have all of the shared libraries and any other dynamicly-loaded resources for every supported architecture present on all of the machines involved, which typically added about 15-20% to executable filesize per arch. And for anything doing builds, you needed to have the header files for all platforms around, also. Note that the GNU tools themselves include a certain search path where they look for cross-compilation tools using long pathnames involving a tuple somewhat like the autoconf target specifier, something like: "toolname-vendor-arch-version" That much would still work on FreeBSD, but big issue comes in creating, importing, and updating the cross-platform shared resources in an organized fashion so that the GNU tools can find it, and there is a ton of glue work that goes into things like ld, ldd, ld.so.1, ar, and the Makefile infrastructure to fully support multi-architecture development. I'd be happy to help where I can with regard to this, but it's not a minor task-- there's a lot of moving pieces and work involved. -- -Chuck