Re: Tiny GCC: Pure, Unadulterated, Object Code

[Brian Dessent <brian at dessent dot net>]

Michael Witten wrote:

> I still don't understand why gcc imposes these libraries, when they
> have nothing to do with compilation. It just seems like bad design.

You can't divorce a compiler from the target.  The target's ABI
specifies a great number of details that are very much relevant to the
compiler, such as:

- calling conventions
- how assembler names are decorated
- size of pointers
- how SIMD and floating registers are passed and saved/restored
- alignment of the stack
- struct and bitfield padding
- register used for PIC and how PIC code is generated
- how TLS variables are created and accessed
- method for unwinding the stack for exception handling
- accessing shared variables and calling into shared libraries
- etc.

As an example I present Linux (ELF) and Windows (PE).  These both run on
identical ia32 and x64 hardware.  But they could not be more different
in a number of the above.  For example ELF uses PLT/GOT for indirection
for shared libraries, PE uses dllimport/dllexport.  ELF requires PIC for
shared libraries, PE does not have a real notion of PIC.  Linux x86_64
is lp64 whereas Windows x64 is p64 (long is 32 bit.)  Windows uses SEH
for EH, Linux uses DWARF2 for EH. The differences continue on and on. 
These two compilers are nothing alike, though the target the identical
hardware.

So you can't just make some kind of generic "386" gcc and expect it to
have any kind of useful ability, unless you are only ever doing to
compile 100% freestanding code like a kernel or a OS-less bare metal
system.  Otherwise it must be targeted to a specific platform, i.e.
i386-pc-linux or i386-pc-mingw.

Brian