Re: Tiny GCC: Pure, Unadulterated, Object Code

[Brian Dessent <brian at dessent dot net>]

Michael Witten wrote:

> > 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.

But it doesn't matter!  Say that gcc could understand all of ELF and PE
semantics in one binary.  You would still require a switch to tell it
which personality to use to interpret the code.  And this switch would
be mandatory for every compilation, because otherwise it would have no
idea what you want.  So how is invoking "gcc -mtarget=linux" any
different than just invoking "i686-pc-linux-gcc"?  It's not.  You
haven't solved anything or changed anything.  In fact I can do this with
no changes to gcc at all, just write a gcc shell wrapper script that if
it sees -mtarget=linux it invokes i686-pc-linux-gcc, if it sees
-mtarget=mingw it invokes i686-pc-mingw32-gcc, if it sees
-mtarget=freebsd5 it invokes i686-pc-freebsd5-gcc, and so on.  Whether
you have them as separate binaries or all in one, it *still* *doesn't*
*matter*.  The details of the target cannot just be abstracted away into
something that you can ignore, they are vital to the context in which
the code executes.  They matter at every point of the process, from the
highest level on down to the very lowest level.

Brian