This is the mail archive of the crossgcc@sources.redhat.com mailing list for the crossgcc project.
See the CrossGCC FAQ for lots more information.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
* 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.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |