EpicGamesExt
Disassembler Features (Debug-info-driven disassembly start addresses, line number toggling, hex/oct case consistency)
Add an option to view an integer whole with zeros in front.
It's most often not a number and the zeros mean something.
Prevent disassembling of pages that are not RX.
This is worse than useless, sometimes the disassembler starts at a few bytes before the actual code, and the instruction gets sliced in half.
It should always start at the page boundary (start of a RX section). (I believe that presently it starts disassembling right from the exe header (right from "MZ" for PE).)
(In this code I was testing how OF and CF behaved. Some parts are useless.) Actual code:
xor eax, eax
mov ecx, 0x80000000
neg ecx
seto al
int3
xor eax, eax
neg eax
setc al
int3
ud2
xor eax, eax
ret
Code should not be disassembled after the end of .text. Instead of add [rax], al, display something like
times (align_up(current_address, 0x1000) - current_address) db 0
Also, numbering the disassembled lines serves no purpose, for "identification" there are addresses already.
That said, the case of hex digits a-f/A-F is inconsistent between the memory view and the disassembly.
I don't know of a debugger that does disassembly reasonably like I'd wish, you'd perhaps be the first one.
To clarify, I haven't tinkered much, having said, "Add an option", maybe such an option exists. The other points stand though. (wait, edit exists? :))
Prevent disassembling of pages that are not RX.
This is not a sufficient rule, as RADDBG can apply any of its visualizers to any memory, including memory which is not within a process at all. I think the primary issue you're seeing is this:
sometimes the disassembler starts at a few bytes before the actual code, and the instruction gets sliced in half.
The disassembly does always start at page boundaries, but this is not sufficient. There is, as far as I can tell, no foolproof way to find a valid starting address without debug information (especially given that disassembly must not only apply to code within loaded EXEs but dynamically allocated/generated data, e.g. for JITs). But when debug info is around, the debugger should indeed use it to adjust the starting disassembly address. This is on my list.
For now, when you want disassembly to start at a precise address, rather than auto-snapping based on instruction pointer position, you can explicitly use the disassembly visualizer applied to some expression. To do this, you can evaluate the address you want in the watch window - e.g. 0x1000 - and then put disasm (optionally something like disasm:{size:N}) in the "View Rule" column. That will actually start disassembling from that address.
numbering the disassembled lines serves no purpose
This I do not agree with, as the line numbers are not there merely for identification. They can be used to count instructions, and they act as a hoverable margin to correlate line information between disassembly and source code. But, also in the source view, an option to disable line numbers altogether is not a bad idea, and at some point that will likely make its way in.
