Hi,
I noticed that the source code through assembly in UASM is not defined correctly in the pdb file, perhaps this bug has another reason, maybe it's a debugger flaw, in any case, when compiling through a macroassembler, the source code is loaded, when compiling through uasm, the source code is not visible, I attach to the message two test cases, if someone wants to look.
Does anyone have experience in debugging through windbg? Very curious, if it recognizes the source code :icon_rolleyes:
It is not easy to work with WinDbg
You need to lead exe to the location where is the PDB file
You need to manually do that.
Play a bit around until you get it
It is much easier to use MSVC than WinDbg
There is nothing wrong with UASM.
It produces a proper debug info, otherwise Visual Studio wouldn't work either.
The /ASSEMBLYDEBUG flag in one of the batch files for the linker is for managed stuff (.net like C# etc), although I dont know if it is effecting the linking and pdb creation.
Quote from: habran on September 29, 2018, 10:29:50 PM
It is not easy to work with WinDbg
You need to lead exe to the location where is the PDB file
You need to manually do that.
Play a bit around until you get it
It is much easier to use MSVC than WinDbg
There is nothing wrong with UASM.
It produces a proper debug info, otherwise Visual Studio wouldn't work either.
Hi habran, fearless,
I mean, we are talking about x64dbg, I mentioned Windbg just for comparison :idea: If MS visual studio perfectly loads the source, in this case, the problem is in x64dbg ...
QuoteThe /ASSEMBLYDEBUG flag in one of the batch files for the linker is for managed stuff (.net like C# etc), although I dont know if it is effecting the linking and pdb creation.
That's right, I just experimented and did not remove this flag.
I know that the debug source asm view in x64dbg is still awaiting to be properly re-implemented. Older versions work as they used dbghelp as the main library to handle this. Newer snapshots are using msdia for pdb symbol loading, but the debug source asm view part is still being worked on and doesnt load at the moment.
It's a feature that I used only once or twice for experimenting. My code is often macro-heavy, and then the debugger (Olly or X64Dbg) has no idea what the source means. If there are no macros, the disassembly is only slightly different from the source, mainly because the .if ... .else ... .endif and loop constructs.
Quote from: fearless on September 30, 2018, 12:55:07 AM
I know that the debug source asm view in x64dbg is still awaiting to be properly re-implemented. Older versions work as they used dbghelp as the main library to handle this. Newer snapshots are using msdia for pdb symbol loading, but the debug source asm view part is still being worked on and doesnt load at the moment.
Got it, thanks! :t
QuoteIt's a feature that I used only once or twice for experimenting. My code is often macro-heavy, and then the debugger (Olly or X64Dbg) has no idea what the source means. If there are no macros, the disassembly is only slightly different from the source, mainly because the .if ... .else ... .endif and loop constructs.
Indeed with macros and high-level code it's harder to see something, but if the code is linear, it uses many constants, repeating blocks of permutations or working with matrices, in this approach it is very convenient to debug the code :eusa_dance:
The latest snapshot has re-implemented the debug source view capability. Highlight a line that has a source line number in the comments, right click, open source view
(https://i.postimg.cc/fbWCW1LK/srcview1.png)
(https://i.postimg.cc/8CyH7wfV/srcview2.png)
deleted
F8 to step source
Thanks for the news! There is no syntax highlighting :icon_rolleyes:, but everything works as it should :P.