This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Shell wrappers and GCC - FYAu
- To: "Paul D. Smith" <psmith at gnu dot org>
- Subject: Re: Shell wrappers and GCC - FYAu
- From: "Zack Weinberg" <zackw at Stanford dot EDU>
- Date: Fri, 29 Jun 2001 09:21:20 -0700
- Cc: Andreas Schwab <schwab at suse dot de>, Fergus Henderson <fjh at cs dot mu dot oz dot au>, Joern Rennecke <amylaar at redhat dot com>, Neil Booth <neil at daikokuya dot demon dot co dot uk>, Bruce Korb <bkorb at veritas dot com>, gcc at gcc dot gnu dot org, help-make at gnu dot org
On Fri, Jun 29, 2001 at 10:27:27AM -0400, Paul D. Smith wrote:
>
> I'm totally lost on the context here (what exactly are you trying to
> accomplish?) since I wasn't privy to the origins of the thread.
>
> However, I don't like adding a new magic symbol, either, if possible. I
> would prefer something like:
>
> CC := $(dynload $(shell gcc -print-dynamic-driver))
That seems reasonable as a syntax, if we're willing to accept changing
Makefiles in order to enable this feature. I'd kind of like to see a
scheme that didn't require changing any Makefiles; there are lots of
packages out there that don't use autoconf and therefore won't get it
automatically.
> Of course, I'm talking pure syntax here, since I have no real idea what
> this is supposed to do. Is the idea that the compiler is a
> dynamically-loaded module and make would invoke the compiler as a shared
> library, instead of fork/exec?
Not the entire compiler, just the "driver". /usr/bin/gcc is a wrapper
executable that rearranges the argument list and then spawns two or
three processes that do the real work. The idea here is to get Make
to call cc1 and as directly, avoiding the process startup overhead
for the driver.
I'm not sure how much of a performance win this would be on a modern
system that has a nice fast process spawn path. Certainly we want to
make the driver itself go as fast as possible, first.
[people *have* suggested making the compiler proper into a dynamic
library, but I don't think they appreciate how hard that would be, and
I think the performance gain would be minimal compared to the gains
available from better algorithms. Also, the driver can be a small
chunk of code that we trust not to crash and kill Make. The compiler
is much bigger and buggier. We want those process boundaries.]
--
zw A man who has never gone to school may steal from a freight car, but
if he has a university education, he may steal the whole railroad.
-- Theodore Roosevelt