tinycc-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Tinycc-devel] Compiling qemu-0.8.2 with tcc (yes, I am insane).


From: Dave Dodge
Subject: Re: [Tinycc-devel] Compiling qemu-0.8.2 with tcc (yes, I am insane).
Date: Fri, 13 Oct 2006 00:12:21 -0400
User-agent: Mutt/1.5.12-2006-07-14

On Thu, Oct 12, 2006 at 04:35:31PM -0400, Rob Landley wrote:
> I just don't see why what machine you're running the compiler on is
> any of the compiler's business.  It should only care what machine
> it's producing target binaries for.

I agree that in an ideal situation all of the backends would be
built-in and selectable at runtime.  There's no real technical reason
why this shouldn't be possible.

> > There's also minor variations in the 
> > architecture support itself, for example the Win64 ABI is LLP64 on
> > x86_64 instead of the LP64 design that everyone else uses.
> 
> And you have a code generator backend.  Currently specified by the
> name of the compiler binary you're running, but "-m arch" would work
> too.

There's still some slightly tricky bits, because -m has some
interactions/dependencies on the compiler's header files and the -I
and -m options are therefore not completely independent.  In the
particular case of Win64 vs. 64-bit Linux on the same target machine,
compiler-related values such as ULONG_MAX would be different.

Perhaps more complicated than it's worth, is the idea that the
compiler header contents can be built into the compiler and generated
internally at runtime based on the architecture selection.  C doesn't
actually require there to be disk files for things like "limits.h" --
it just says that the directive "#include <limits.h>" causes certain
things to become visible to the translator somehow.

> Sane defaults remain a good thing, so you'd probably want some kind 
> of "-nostdcrap" argument at the start of that...

Yes, and you want to be sure it's truly independent of the host
environment.  As you're probably aware, in the past it's been
notoriously difficult to configure a GNU toolchain to be 100% divorced
from the host environment.  For example if you want to cross-link
against uclibc while running on a glibc system with the same target
hardware, I think the only reliable way to do it is by chrooting into
a uclibc host environment.

                                                  -Dave Dodge




reply via email to

[Prev in Thread] Current Thread [Next in Thread]