Re: Tiny GCC: Pure, Unadulterated, Object Code

[Michael Witten <mfwitten at MIT dot EDU>]

On 29 Jan 2008, at 12:05 AM, Brian Dessent wrote:

> Michael Witten wrote:
>
> > What you describe is not related to compilation to an intermediate
> > language, which is all distcc really requires.
>
> It still very much matters, because the intermediate language  
> depends on
> all those aspects of the target ABI. (And even then, the IL is not  
> what
> gcc writes out; it's the generated assembly.)

That's true for GCC; however, I think everybody agrees GCC is FUBAR.
That being stated, I want to stress that I was replying in theory (as
much as I can), as your original posting strayed from the particular
case of GCC to the general.

> They are fundamental to how the code is parsed, optimized, and  
> generated.
> A linux targeted gcc would have no idea how to even parse  
> __declspec((dllimport))
> just as the PE gcc would not be able to make any sense of  
> __attribute__((visibility,
> "hidden")).  They would simply choke and die because the code to  
> handle those
> features just wasn't physically compiled in.

Indeed! This is because GCC doesn't do the right thing. It does  
something very stupid by
translating the code directly into a mishmash of low- and high-level,  
platform specific,
object code. Moreover, it emits this cruft that it expects to find in  
libraries. It all
reeks of a hackish and just-get-it-done mentality.

I haven't looked too much into it, but the guys at LLVM seem to know  
what they're about.
No doubt, many GCC developers are super knowledgeable, but they're  
left with this kludge
to maintain. I encourage developers here to jump ship and start  
furthering LLVM instead
(though, there is little doubt Apple will force you to work on LLVM  
eventually:
http://gcc.gnu.org/ml/gcc/2005-11/msg00888.html (I have not read the  
thread, so excuse me
if I'm talking out of my arse).

> And that is only one blatant example,
> but all of those things on that list directly affect code generation  
> in a way that
> cannot be ignored.

Yes, they affect final code generation. The GCC isn't fine grained  
enough. Hell, the
configuration process isn't fine grained enough!

> Even the basic assembler directives for ELF and PE are different.

Obviously then, these two should not be considered the same thing.
This betrays an inadequate design in GCC's compilation process.

> There is just no way to make a "generic i386 gcc".

Sure there is: Pure binary.

What you mean to say: There's just no way to make one final meta- 
binary (object code);
however, I'm sure a more generic meta-binary level above ELF and PE  
could be used.

Nevertheless, gcc can be instructed to stop before linking. This is  
what distcc has it
do. Therefore, GCC should be configurable not to produce any libraries  
when it is built,
because they will never be used. In fact, I was able to make a libc- 
less gcc (C/C++) that
works great with distcc; even though no linking ever occurs on the  
servers, libgcc was
still built for every cross-compiler. In fact, with any --target  
involving 'linux',
the gcc build process REQUIRES a libc, because it tries unnecessarily  
to obviate what
would become link time incompatibilities; in order to use distcc, I  
had to build gcc
with --target=i686-elf but mangle the name to i686-pc-linux-gnu, which  
should be wholly
unnecessary. These --target names should really just be convention.

Sincerely,
Michael Witten