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