help-make
[Top][All Lists]
Advanced

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

Re: Shell wrappers and GCC - FYAu


From: Fergus Henderson
Subject: Re: Shell wrappers and GCC - FYAu
Date: Fri, 29 Jun 2001 22:52:11 +1000

On 29-Jun-2001, Joern Rennecke <address@hidden> wrote:
> > charge of calling wait(2).  And the final problem is how does make
> > tell when it's supposed to try the magic -print-dynamic-driver switch?
> > (Obviously it does that only once per make invocation, or what's the
> > point?)
> 
> Maybe you should set an environmnment variable to the output of
> gcc -print-dynamic-driver to enable this scheme.

Basically what you want is a generic way for `make' to invoke a shared
library entry point rather than spawning a new process.

I suggest this be done by adding a special character, say `&', that
you can use as a prefix on a command line (like the existing `@' and
`-' characters).  This would tell make to treat that command as a shared
library -- which would mean dlopen()ing it, using dlsym() to find the
entry point "main"), and then calling that entry point -- rather than
trying to fork() and exec() it or to spawn a shell to execute it.

Then you could use this feature by just setting the `CC' make variable
to contain this special character followed by the name of the appropriate
`.so' file.

        CC := &`gcc -print-dynamic-driver`

Note that using GNU Make's ":=" rather than "=" here ensures that this
will only get evaluated once.  Alternatively, and preferably, this
could be done via autoconf at configure time.

Furthermore, this extends trivially to support programs other than gcc.
Any program which wants to support this feature just needs to provide
a shared library that contains the same code as the executable.

(I'm assuming here that it's OK for a shared library entry point to
have the same name as a function in the executable that loads it; this
seems to work fine on my Linux system but I'm not sure how portable that
assumption is.  At worst you'd have to name the entry point something
different, e.g. "dl_main", for the shared library.)

There are two main drawbacks with this approach:

        1.  There could be problems if the .so files being loaded
            depended on different versions of libc.so or other shared
            libraries than the `make' executable.

        2.  Processes are useful for providing OS-enforced memory
            protection boundaries.  This scheme discards those boundaries,
            which means that if one command invoked by make has a wild
            pointer bug, it might screw up memory used by make or by other
            commands invoked by make, and it might be difficult to debug.
            A mitigating factor is that you could always fall back to using
            separate processes if that turned out to be a problem.
            But this might just hide the (Heisen)bug.

Still, if it gives a significant speedup it may be worthwhile.

-- 
Fergus Henderson <address@hidden>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.



reply via email to

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