This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: matrix linking
On Jan 10, 2006, at 4:32 AM, george@georgeshagov.com wrote:
I have some kind of an idea, which I called 'matrix linking'. It
would appear
this is a new kind of linking.
Sorry, not very new. Microsoft has been doing it longer than we have
I believe.
On Jan 10, 2006, at 10:28 AM, Sean Callanan wrote:
In short, you are proposing that instead of linking an executable,
it be made into a bunch of shared libraries. The function calls
between these shared libraries be arbitrated by a "dispatcher"
which can dynamically reroute function calls.
There already exists a technique to do this if you're willing to
restart your app: incremental linking. Many IDEs support something
like this (it's called ZeroLink in Apple's Xcode, for example), and
even GNU ld has the -r option, which makes an object file
relocatable, making it quicker to link.
If you want to be able to do this without restarting, there are
some challenges:
1) Static variables in modules would present problems, as these
would have to somehow be reinitialized to their values in the old
module (for instance, if you have a static pointer to a malloc()ed
data structure).
-mfix-and-continue handles this case on darwin. See
TARGET_FIX_AND_CONTINUE in the compiler sources for the mods.
Roughly, we keep the old data and don't run the ctors for the new
data as I recall. The runtime linker handles most of the binding
issues, with little modification of the generated code.
3) You would have to figure out how to interpose on functions
called via function pointers.
We do this on darwin by reserving n bytes at the front of all
functions and put nops there, and then the loader patches those bytes
(COW) with a jump to the last one loaded.
4) In a multithreaded application, you'd have to make sure that
module replacement is atomic and you handle the case of replacing a
module at a time where a thread is executing a function in it.
:-)
Perhaps others on this list can come up with more issues to resolve.
I'd phrase it this way, there are certain realities when doing this,
and its important to understand the limitations and gotchas.
On Jan 11, 2006, at 5:16 AM, george@georgeshagov.com wrote:
Interpreter is the weakest thing here, its communication with
compiled code –
especially. By now I am trying to modify GCC (cc1) in such way it
would be
possible to apply matrix linking for .C modules only, C++ by now
looks to be
unsolvable task, that was the purpose of my writing, actually.
C++ can be done without too much work. :-) We do it on darwin. See
the codegen changes done by -mfix-and-continue. The are small, minor
and trivial. With it, we get into the same functionality range as in
Microsoft's compiler.
I need some kind of assistance with cc1 sources.
I'd recommend you copy in spirit the scheme used by darwin, trivial
compiler mods, and then just do up the changes to the runtime linker/
loader. Doing that, you don't need much of any help for the compiler.
I am trying to modify it in such way that during the compilation
of .C module on function description it would automatically produce
additional code (stub-function), and proxy function. These ones to
be compiled by some template, its compiled code (I thing the
assembler) is to be ‘inserted’ in the original module. The entire
calls to the function are to be redirected through the external
matrix.
Slow. We found there wasn't any advantage to making the code slow,
so we didn't. We found that we could get near to 100% speed of
normal code, the biggest slowdown being the 5 nops or so at the start
of each function, which, on modern machines, go very quickly.
What advantage do you think that making the code slow gives you over
the scheme used on darwin?