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.
