Re: weird limitation on the system's binutils

On Sat, Jul 01, 2006 at 10:08:03AM -0400, Chuck Swiger wrote:
> 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"
Exactly, I have the impression that arch-vendor-system-<toolname>
is the way to go if several crosstools are needed simultaneously.
And this is how GNU toolchain installs itself by default if
cross-compiling.
> 
> 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.
Another issue is that, again AFAIK, interface between bfd and rest of binutils
code is highly fragile and changes in subtle ways between versions.
It is not supported and definitely causes bugs to mix bfd and the rest
from different version of binutils.
> 
> 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.
Completely agree. From my experience with cross-tools, I had to
carefully select version of binutils and gcc for given target. And,
sometimes, augment chosen version with patch found somewhere.
As I see it, having specific ports for each arch, that is maintained
individually, gives much less maintainance work.

BTW, are there plans for updating binutils in the base system ?