Optlink is on github

[Walter Bright]

On 3/7/2013 4:35 AM, Daniel Murphy wrote:
> Maybe I'm missing something, but I don't understand why this is necessary.
> It should be trivial to look at the map file for the closest preceding
> label.  On modern toolchains it should even be possible to compile the asm
> with debug line information.  Or is grepping more effective than it sounds?

Modern operating systems load programs at different base addresses each time, so 
the addresses in the map file don't match up with the addresses at run time.

The older assembler I was using didn't emit symbolic debug info. I haven't tried 
out ML that way.


> This sounds completely insane. (But also fun, in an extremely frustrating
> way)
> I suspect it would be easier to reverse-engineer microsoft's (or borland's?)
> old linker from the disassembly, if they wrote it in C.

You'd be incorrect if you thought MS's or Borland's linker was better. Optlink 
sold very, very well against those linkers back in the day, because Optlink was 
far better.


> As a side note I actually wrote an omf (dmd-emitted subset) linker last year
> that gets through almost all of the dmd test suite.  It has no debug info
> support, which sucks, but it may work in some cases where optlink can't
> cope.  It is fairly naive performance-wise, but is written in a much
> friendlier language.
>
> If anyone is interested I'll put it up on github.

There's much more to making a linker. There's the debug info (which you 
mentioned), then there are the resource files, the module definition files, and 
lastly the myriad of rather complex switches that are expected. Almost none of 
that is tested by the dmd test suite.