Re: weird limitation on the system's binutils

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