Re: Are Better Linkers Possible?

>From article 91-08-102, by westfal@mprgate.mpr.ca (Ron Westfall):
> As a follow-on to my previous post, I would like to pose a question.
> It seems obvious to me that in the last few years compiler technology
> has advanced rapidly to handle object-oriented languages, etc., but
> linker technology has not kept pace. If you had the opportunity to
> design a new linker from the ground up, what features would you give
> it beyond what linkers typically have now?


I would give it the ability to be programmed. The linker on a certain brand
of workstations will create a data structure in memory when special symbols
are referred to (and not create them if they are not referred to). Since it
only creates this one data structure it is very useful it you need that one
data structure but not so useful if you need some slightly different
information.


In some of my C++ programs I would like to know all of the data members in
some classes. The linker has easy access to this info and could create some
in-memory tables with that data. But different programs may need different
data. So the linker should be programmable to be able to defined when to
create the data and what data to create.


There have been a couple of papers recently on adding code to a running
program (incremental and dynamic linking). An some on adding classes to a
running C++ program (with strong type checking still enforced). I think these
ideas should be applied to the linker itself to make a linker that can be
programmed by dynamically linking code into the linker.


Any code in the linker that does not do what you want in the linker could be
replaced to do what ever you want. For example, if the linker had exhausted
its places to look for a symbol and still not found it, it could call a
(replacable) function in the linker to resolve it. That function might create
a data structure in memory to resolve the reference.


I recently needed to place all .data in write-protected memory. My linker
does not support it, so I am out of luck. (I don't really want to edit
assembly code.) If the linker was programmable I could fix it.


My main point is that the linker should be programmable using dynamic
linking in the linker itself.


Brian Beuning
--

Return to the comp.compilers page.
Search the comp.compilers archives again.