From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20924 invoked by alias); 29 Jan 2008 06:11:59 -0000 Received: (qmail 20911 invoked by uid 22791); 29 Jan 2008 06:11:58 -0000 X-Spam-Check-By: sourceware.org Received: from BISCAYNE-ONE-STATION.MIT.EDU (HELO biscayne-one-station.mit.edu) (18.7.7.80) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 29 Jan 2008 06:11:32 +0000 Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.13.6/8.9.2) with ESMTP id m0T6BTCr016815 for ; Tue, 29 Jan 2008 01:11:29 -0500 (EST) Received: from MACGREGOR-TWO-TWELVE.MIT.EDU (MACGREGOR-TWO-TWELVE.MIT.EDU [18.239.5.212]) (authenticated bits=0) (User authenticated as mfwitten@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id m0T6BS3Z010160 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Tue, 29 Jan 2008 01:11:28 -0500 (EST) Message-Id: <2CDFCA36-07C2-4871-8773-15F2DAD35DEB@MIT.EDU> From: Michael Witten To: gcc-help@gcc.gnu.org In-Reply-To: <479EB41F.9930771E@dessent.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: Tiny GCC: Pure, Unadulterated, Object Code Date: Tue, 29 Jan 2008 18:16:00 -0000 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> X-Mailer: Apple Mail (2.915) X-Spam-Score: 0.00 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/msg00315.txt.bz2 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