[Issue 14497] Disassembly view

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=14497

--- Comment #4 from Manu <turkeyman at gmail.com> ---
(In reply to Rainer Schuetze from comment #3)
> My current idea is to abuse the "Code Definition Window" to show assembly
> instead. The assembly would be a file produced by compiling and dumping the
> file after saving it (or maybe after some new command invoked by a hotkey).
> The caret location inside the dump file would update according to a line
> number change in the editor.

This sounds like an awesome start!

> > Short of source, at very least, there needs to be symbol names at the header of blocks of code. 
> 
> There are, but I'd like to avoid having to figure the actual mangled D
> symbol from the source (though feasable). Using debug line numbers seems
> better for navigating larger functions.

Seems very reasonable, probably better.
If the caret is able to follow the cursor in the editor window, then we'll have
a really useful tool I think.

> > Do the GNU tools make this easier? 
> 
> The objdump tools that come with GDC or LDC don't produce really helpful
> results (and don't work on OMF and MS-COFF). When compiling to assembly, GDC
> adds location information which could be used, LDC does not (I might be
> missing some command-line switch, though). DMD can't build to asm anyway, so
> dumping an object file will be necessary anyway.

So... as I see it, with the DMD compiler landscape as it is, the most important
compiler in this case is LDC. If you're doing performance work for Windows, I
think it's fairly safe to say you're using LDC, since it's the only compiler
that can link against other VS code, and produces high-performance output.
While DMD output would ofcourse be useful, I'm not sure there's as much value
analysing DMD output because it's a pretty average codegen anyway. I doubt many
people would optimise for DMD?
The real money is on analysing the output from LDC, since for optimised builds,
I think that's the compiler that will typically be used for Windows codegen,
no?

> Maybe I can rip some code from cv2pdb, it can read line number information
> from executables with CV4 and DWARF debug information. I'll have to add CV8
> support for Win64 though.

That sounds like a lot of work. I kinda hoped this would be a relatively simple
feature with tools already available, the trouble being to integrate it into
the VS UI/menu.
But yeah, I think you can clearly see the problem space, and it sounds like you
have some personal interest in this too, so I'll leave it to your good
judgement from here.

I'm super excited you're interested in this idea! :)
Thanks again!

--