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
