Since my last post, I’ve written a prototype implementation of relinking for the incremental compiler.
Now, the compile server will create an object file in a cache directory. If there was a previous variant of the compiled file in the cache, it will then link the two together (using ld -r
). Then, the final object file is copied from the cache to the user’s requested output file.
So, now you can “make clean; make
” and see correct results from the incremental compiler. The new results table:
Compiler | Seconds |
---|---|
Trunk | 30 |
Incremental, no server | 30 |
Server, first run | 26 |
Server, second run | 17 |
This is probably the current best (or “best worst”) case — no actual recompilation needed to be done. In terms of user scenarios, this corresponds to, say, modifying a comment in a core header file and recompiling. And, given that this is execing both ld
and cp
, the results aren’t too bad.
On the other hand, I had somewhat higher expectations. I’ve been pretty depressed about this project all week. Relinking is turning out to be a pain; I’m pretty much convinced now that incremental preprocessing is a necessity; and this combination makes me wonder whether I’m chasing a rat down a hole. The question of whether this project remains worthwhile is normative one, and fairly subjective. That’s a fancy way of saying, I don’t know.
Ugh.
Mostly I try to think about it in terms of a success metric. Or, what is the minimum expected gain that would make it appear to be worthwhile? I suspect I may need to prototype the C++ compiler changes before I can really satisfy myself on that topic, though.
Back to the concrete.
The linking prototype is still pretty bogus. It arrives at an executable which works, but the intermediate object files grow over time. That’s because it is pretty hard to coerce ld
(and objcopy
) into doing the odd things I want: I want to link two files together, yielding another relinkable object (i.e., I need -r
), where symbol name clashes are always resolved in favor of the first file. You’d think -z muldefs
(I’ve gotten overly familiar with the ld
manual) would work here, but it just drops the symbols — not the contents. So, maybe -ffunction-sections
and --gc-sections
is the way to go — but this also has problems; the former because (supposedly) it does not work with all programs, and the latter because it interacts oddly with -r
.
I’m still hoping I can get by with a relatively simple linker hack, though as the week has dragged on I’ve realized that my understanding of linking is less than ideal.
Be the first to leave a comment. Don’t be shy.