From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4014 invoked by alias); 29 Jan 2008 06:54:53 -0000 Received: (qmail 4002 invoked by uid 22791); 29 Jan 2008 06:54:52 -0000 X-Spam-Check-By: sourceware.org Received: from dessent.net (HELO dessent.net) (69.60.119.225) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 29 Jan 2008 06:54:35 +0000 Received: from localhost ([127.0.0.1] helo=dessent.net) by dessent.net with esmtp (Exim 4.50) id 1JJkMR-00030G-18; Tue, 29 Jan 2008 06:54:23 +0000 Message-ID: <479ECD9F.C1ACE93B@dessent.net> Date: Tue, 29 Jan 2008 18:36:00 -0000 From: Brian Dessent Reply-To: gcc-help@gcc.gnu.org X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) MIME-Version: 1.0 To: Michael Witten CC: gcc-help@gcc.gnu.org Subject: Re: Tiny GCC: Pure, Unadulterated, Object Code References: <47988297.40C3C762@dessent.net> <83DE5DDC-09DE-4C4A-92E5-8ED60D9375A1@MIT.EDU> <479ABB8F.92A93776@dessent.net> <124F1299-01FD-4B0C-A5A2-392B2D12B77C@MIT.EDU> <479EB41F.9930771E@dessent.net> <2CDFCA36-07C2-4871-8773-15F2DAD35DEB@MIT.EDU> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org X-SW-Source: 2008-01/txt/msg00316.txt.bz2 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