Re: Cross compile error question: i686 to powerpc--linux-gnu

["M. R. Brown" <mrbrown at 0xd6 dot org>]

* William A. Gatliff <bgat@saturn.billgatliff.com> on Wed, Oct 17, 2001:

> 
> The SH version of gcc has helper functions with names like __udivsi3,
> __ashlsi3, and __mulsi3, which implement primitive operations that
> aren't natively supported by the microprocessor.  I'm not intimately
> familiar with very many other gcc's, but I suspect that all ports have
> at least a few helper functions.  Gcc inserts calls to these functions
> in the code it generates, rather than inline the equivalent asm code.
> 
> The trouble is, I DON'T KNOW WHEN THESE FUNCTIONS ARE BUILT during the
> compiler construction process.  Some of them are implemented in C
> (soft-float, for example), and so they *can't* be built by the
> bootstrap compiler because you don't have enough of an environment to
> build them.
> 

Heh, I can tell you that... they're built as part of libgcc, which gets
built whether you're building a bootstrap compiler or not.  That much isn't
rocket science.

The only reason gcc needs to rely on system headers and libraries is for 
threading and shared library support (e.g. building a threaded and/or shared
version of libgcc and startup files) and for building higher-level components
like libiberty and g++. For System V ABI targets, Linux, etc. it does *link*
with startup files that don't exist until glibc is built and installed.

Startup files are partially gcc's responsibility and partially ld's
responsibility - the linker script specifies the main startup file, but
gcc's specs often define "variants" of those startup files (e.g. for C++
constructor/destructor code, profiling, etc.).

> You don't need these functions to build libraries, obviously, but you
> do need them to build applications.  The set of helper functions
> needed for any particular configuration and application is highly
> application and configuration specific.  So I can't make a blanket
> statement like "you don't need anything other than the bootstrap
> compiler" without doing a lot of non-gratis research.
> 

Actually, if you do an unsigned 32-bit integer division on the SH you do
*need* __udivsi3_i4, whether you're building library code or application
code - it's a compiler intrinsic and you can't escape it :P.  Whether or not
libgcc is linked statically or shared depends on if you're using 3.0+, and
whether you've bothered to build the full compiler.

> 
> I can't speak for anyone else, but my stuff tends to be a mixture of
> -c's, -o's, and just straight gcc's, depending on what I'm up to that
> day.
> 
> I think that gcc's automation of the whole process is an artifact of
> its native compiler heritage.  This is a Good Thing, for me anyway.
> 

It's a Good Thing as long as you know how to "opt-out" of certain
compilerisms by using gcc's extensive options.  I'd suggest anyone
seriously working with gcc read it's info pages, particulary the node
"Invoking GCC".  Especially read up on target-specific options.

M. R.

PGP signature