Porting gcc without porting Binutils? - gcc

I am new to porting gcc, just want to ask, if I only want gcc to generate assembly language for each files can I skip porting Binutils ?

Sure. Are you trying to port gcc as cross-compiler? You should configure with --disable-bootstrap and use make all-gcc when building it (i.e. skip libgcc, glibc, libstdc++ build). Then you will get pure compiler to work from source to target assembler only.

Related

Identify Compiler Versions with arm-none-eabi cross compiling

I'm trying to figure out the compiler versions that are used in my project (to sync them across the team).
I'm using ChibiOS on an STM32 and it uses a makefile to compile. In the Makefile it uses
TRGT = arm-none-eabi-
CC = $(TRGT)gcc
Which makes it clear that arm-none-eabi-gcc is being used. However unclear to me is, if the version of my gcc compiler (gcc --version) is at all relevant to the compilation. As far a I understand gcc just is being set to a specific target here? Whats the relationship between my gcc/cc executable and the arm-none-eabi-gcc executable?
There is no relationship. It is a separate compiler which usually comes with its own include files, libraries, startup file and linker scripts. Usually, it is called a toolchain as often it comes with other tools as well (linker, specific versions of gdb and other tools).

AVX and newer intrinsics with GCC on Mac; what assembler would one need?

I have been tweaking GCC 6.3.0 to get it to use the libc++ runtime instead of libstdc++ so that g++ can be used without worrying about C++ runtime incompatibilities:
https://github.com/RJVB/macstrop/tree/master/lang/gcc6
The tweak works, I can build and run KDE software using g++ against Qt5 and KF5 frameworks (and everything else) built with various clang versions.
What doesn't work is generating code that uses AVX and presumably most or all newer intrinsic instructions.
This is not a new issue that's never been invoked on here; it's answered here for instance: How to use AVX/pclmulqdq on Mac OS X
Evidently one can configure gcc to call the linked script instead of the actual as executable.
But can gcc not be configured to use another assembler altogether, like nasm, and would that solve this issue?

Why do cross-compilers have a two stage compilation?

I currently try to understand how cross-compilers work. I'm a bit confused about the two-staged compiler compilation process.
As far as I read, the following procedure is applied:
Compile bintutils for the target architecture
Compile GCC (stage 1)
Compile newlib/eglibc/... with GCC
Compile GCC with the libc (stage 2)
Why is there a second stage involved? Couldn't I just invoke the first stage compiler with some flag like -lc to include libc?
I'm not sure why gcc has such a complicated build process. My clang/LLVM based ELLCC (http://ellcc.org) cross tool chain project builds like this:
Compile the compiler (using either gcc or a pre-built version of the ELLCC compiler available from the web site.).
Use the compiler to build the C++ and C libraries for all targets.
Build binutils and gdb for all targets (for all targets: don't make target specific utilitities except for the assemblers. ld, gdb, objdump, etc. all support this)
(optional) Use your newly built compiler to cross build itself for all the targets.
BTW, ELLCC currently supports ARM, Microblaze, Mips, PowerPC, and x86 targets for Linux and bare metal execution environments.

How to choose the assembler GCC uses?

Is there an option to GCC that changes the path of the assembler it uses? I'm getting errors from Solaris /usr/ccs/bin/as when using GCC to attempt to compile Haskell, but I've got a copy of GNU as in my path so when I type which as and as --version they use the GNU version, not the Solaris version. Unfortunately it seems GCC ignores the GNU version in the path and goes to the Solaris version. I'm trying to build Haskell on Solaris and I don't think it sits well with the Solaris assembler. I hope I can change this behaviour with a simple wrapper script so I don't have to recompile GCC.
Specifying the assembler to be used is not possible at run time. It has to be done when configuring gcc:
--with-gnu-as
Specify that the compiler should assume that the assembler it finds is the GNU
assembler. However, this does not modify the rules to find an assembler and will
result in confusion if the assembler found is not actually the GNU assembler.
(Confusion may also result if the compiler finds the GNU assembler but has not
been configured with --with-gnu-as.)
Note the part I've put in italics. Of course you could temporarily change /usr/ccs/bin/as to call the gnu assembler (provided you have the necessary permissions), but the above seems to suggest that you'll very likely run into problems. The gcc build process actually checks the features the assembler supports and generates code for exactly that assembler.
I suggest you build a new version of gcc first (configured to use the gnu tools), and then use that to build ghc.

Does llvm/clang still need MinGW gcc after built?

I am new to llvm/clang and have successfully built clang with MinGW.
I have one simple question - is MinGW gcc still needed for clang to work as a c/c++ compiler?
Thanks,
jweiboman
Right now - unfortunately, yes. clang will use gcc to assemble / link the stuff. This is necessary to e.g. provide the proper cmdline for linker invocation adding CRT objects & libraries.
As soon as someone will provide the the complete "toolchain" definition for mingw in clang, this won't be necessary. Only assembler and linker (part of binutils) will be required.

Resources