Optlink is on github

[Daniel Murphy]

"Walter Bright" <newshound2 at digitalmars.com> wrote in message 
news:khaplp$nn5$1 at digitalmars.com...
> 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.
>

You can turn windows 7's aslr off.

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

Looks like the /Zd swich gives you line numbers.

>
>> 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.
>

That's not what I meant.  I mean that when trying to work out what the 
assembly does, having real stack frames and a consistent calling convention 
could be more useful than knowing the label names and having out of date 
comments.

Optlink is lightning fast and memory efficient, but honestly most of the 
time you don't care.  Computers these days are ridiculously overpowered for 
something as simple as linking.

In huge projects this matters more, but then you start running into 
optlink's limitations.

>
> 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.
>

Yeah, debug information is fairly nasty.  It is at least as hard to 
implement as the actual linking.  (I have done some work on this for CV4, 
just not finished)

I don't expect res and def support are anywhere near that complicated.  Same 
goes for most of the command line switches.  (I have read through the list, 
but it's possible I'm being overconfident here)

> However, Optlink does bring considerable value to any linker replacement 
> project, in that embedded in it is an enormous amount of lore about all 
> those twinkie little things that matter, and how things really need to 
> work.

Optlink also has a lot of support for dead file formats/memory models and an 
insanely convoluted code base.  Like you said, porting to C doesn't escape 
this.