I want to disable assembly and see pure C/C++ code during debugging using Trace32.
is it possible to do that?
The command Mode allows to switch the display mode.
Mode.Asm : Assembly only
Mode.Hll : Source code only
Mode.Mix : Assembly and source code
The current mode also determines whether a step executes an assembly instruction or a source code block.
There is a mode button, which is used to switch enable/disable assembly in debugger.
Related
TL;DR: Debuigging into MFC (CString) header code does not work on both my machines and as far as I can tell this is due to the peculiar way these headers are compiled.
Stepping through MFC header code when entered via disassembly works, but setting brealpoints does not work.
I'm looking for a workaround or at least acknowledgement of my analysis.
System:
Visual Studio 2019 Professional 16.9.6
Windows 10 / 1809 Enterprise LTSC
Setup: (I do apologize for this being rather long.)
Create a Visual Studio 2019 Example MFC Application Project (SDI App)
Make sure Enable Just My Codeis off under Options -> Debugging -> General.
Set the build configuration to Debug/x64 (does not make a difference, but let's all stay on the same page)
Navigate to MFCApplication1.cpp -> CMFCApplication1App::InitInstance()
Insert a CString init like this:
...
InitCommonControlsEx(&InitCtrls);
CWinAppEx::InitInstance(); // please put breakpoint 1 here
// Add this line and set breakpoints
CString this_is_text(L"Debugging into CString Header does not work!"); // breakpoint 2 here
Now, you can start the program under the debugger, and you should stop at the first breakpoint:
Now, make sure all symbols are loaded, easiest done via the Call Stack:
Just select all lines in the call stack window and hit Load Symbols in the context menu. Afterwards the call stack should look roughly like this:
> MFCApplication1.exe!CMFCApplication1App::InitInstance() Line 75 C++
mfc140ud.dll!AfxWinMain(HINSTANCE__ * hInstance=0x00007ff7b5070000, ...) Line 37 C++
MFCApplication1.exe!wWinMain(HINSTANCE__ * hInstance=0x00007ff7b5070000, ...) Line 26 C++
MFCApplication1.exe!invoke_main() Line 123 C++
MFCApplication1.exe!__scrt_common_main_seh() Line 288 C++
MFCApplication1.exe!__scrt_common_main() Line 331 C++
MFCApplication1.exe!wWinMainCRTStartup(void * __formal=0x000000c2b7084000) Line 17 C++
kernel32.dll!BaseThreadInitThunk() Unknown
ntdll.dll!RtlUserThreadStart() Unknown
Now, you can try stepping-into (possibly F11) the CWinAppEx::InitInstance() function, which should work without a problem, landing you in mfc140ud.dll!CWinApp::InitInstance() Line 394 - this is OK.
Step out again, and then then try to step-into the CString ctor:
This DOES NOT work on my machine(s)!
What I can do however, is (from the point above) switch to disassembly view, step into the calls there and get into the header code this way:
I can then successfully step through (but never into) the MFC header code. Trying to set a breakpoint will result in the error:
The breakpoint will not currently be hit. No executable code of the debugger's code type is associated with this line.
Possible causes include ...
C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\VC\Tools\MSVC\14.28.29910\atlmfc\include\cstringt.h
And this is where I'm at.
Analysis:
What we can see from the MFC code is that we can step into "regular" cpp code, but as soon as we try to step into (or set breakpoint) code that is inside this CStringt.h it breaks.
Peculiar here: This is template header code, and still the executed code (as shown by the disassembly) is not in the user module but in the mfc###.dll! I think they do some clever tricks with the preprocessor (see defined(_MFC_DLL_BLD) and somesuch) which enables this multi use of the header file, and maybe, possibly this is also what breaks the debugger.
Question:
Is this a known problem, does this happen with all VS2019 installs, is there something peculiar to my setup?
Maybe fixed in a newer VS version?
Iff this is actually broken, what would be a useable workaround, other than constantly switching to disassembly view when into the MFC headers.
The most interesting answer here would actually be as to WHY this breaks - where does the debugger get confused? Is this a general problem with re-define-ing code when debugging library code?
The source shipped with MSVC does not match.
I think this happen, as DLLs got updated with Windows Update or a new vcredist, but Visual Studio includes are not updated. If you build with /MT or /MTd and link MFC statically, the problem does not persist.
Probably this can be reported to http://developercommunity.visualstudio.com if you care.
Workaround 1
Do steps described by #selbie:
Set a breakpoint on the line of code I want to step into.
When
the breakpoint is reached, right click in the editor window and select
"Go To Disassemly".
In disassembly mode, step over until you get to
a call statement. [...] You
can flip out of disassembly mode by right-clicking again and selecting
"go to source code".
(skipped the part not relevant to this issue)
Then pick up the location of the header manually, the debugger will tell that it does not match. The difference seem to be insignificant though, so the header is usable.
Workaround 2
Link MFC statically, compile with /MT or /MTd
Workaround 3
ATL has a similar CString that does not suffer from the issue:
#include <atlbase.h>
#include <atlstr.h>
int main() {
ATL::CString this_is_text("Debugging into CString header works");
}
Analysis went sideways at some point, but we finally found one part of the problem here:
The Require source files to exactly match the original version option:
was the problem, but in a very peculiar way:
When you do NOT require source files to match (that is, disable this default option), then the erroneous behavior of the OP occurs: The debugger can no longer match the symbols to the cstringt.h file.
Unfortunately, I had this disabled on both machines. Pulling in a third machine showed that we could set breakpoints (though F11 still does not work) and by comparing the xml export of the VS settings we found that this was different.
So, long story short: For us, to be able to set breakpoints in the (unmodified!) MFC header, requires us to enable the Require source files to exactly match .. option.
If the option is disabled, which would imply a more lenient behavior by the debugger, it no longer works.
And, yes, we double checked it's always the same source file at C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\VC\Tools\MSVC\14.28.29910\atlmfc\include\cstringt.h
The mystery with step-into/F11 persists, but I guess this would better be taken to a separate question.
Uncheck the Enable Just My Code option in Tools->Options->Debugging
I know that works for c++ std:: library code debugging. The other technique I do, when I forget to uncheck this option, is similar to what you describe above.
Set a breakpoint on the line of code I want to step into.
When the breakpoint is reached, right click in the editor window and select "Go To Disassemly".
In disassembly mode, step over until you get to a call statement. That's typically the std library. Eventually, you'll navigate into a mix of assembly and system code sources. You can flip out of disassembly mode by right-clicking again and selecting "go to source code".
I am storing some variables inside custom section in my program. During debugging session I can check it is created and that it contains the necessary data. But in release mode, it disappears!
Note: I am also creating an executable section which strangely is created in both version. The CPU platform seems to make no difference.
Why doesn't the "data" segment appear in the release version?
This is a short snapshot:
// Defnitions used for better code segmentation
#define store_variable(x) __declspec(allocate(x)) //for data segment
#define store_code(seg) __declspec(code_seg(seg)) //for execution segment
#pragma section(".eqwrt", read) //weird name because I thought there would be collision
store_variable(".eqwrt") UCHAR USER_DATA[SIZE];
store_variable(".eqwrt") USHORT Version = 1;
store_code(".wsect") bool sendError();
The program (it's a dll) is compiled with a fixed base address and with /MT flag.
Release version x64. Only one segment appears-the executable one:
Debug version x64. Both segments show up:
Try to disable Link-time optimizatizon scheme from the project's settings.
To do that go to: Configuration Properties 🠂 General 🠂 Whole Program Optimisation and set to No Whole Program Optimisation.
Most likely it has something to do with the optimisations performed during linking.
More details you can get from here : What's C++ optimization & Whole program optimization in visual studio
I am using debugging in Visual Studio and disassembler window to get the instruction code in hex, but when the main call a function (as Fig.1), the function instructions appear in a sperate section (as Fig. 2)
Is there any way to show the function instructions appears as a part of the main?
main section in dissasembler window
function section in dissasembler window
Thanks,
Based on mov eax, 0CCCCCCCCh it seems you're working with a Debug build.
In Debug mode Visual Studio does not inline any function by default.
You can switch to Release mode or enable function inlining in compiler settings (C/C++ - Optimization - Inline Function Expansion) and the call to fun() will probably get inlined.
Disassembly is always going to be a separate window, there are options on the context menu for the disassembly window that allows you to control what is shown (source code or not, or instruction addresses or not, for example).
I am writing assembly-level optimized code, and I need to make sure that the C++ compiler is working with it correctly in Release-Mode.
I used to be able to get Release-Mode programs to break on breakpoints in VS 2002 (and display the raw disassembly as I stepped through it), but I can't remember how I got that to work. Does VS 2010 have any options that might allow this to happen?
Compile with /Zi and link with /DEBUG and you'll be able to set breakpoints.
Under a project's Properties dialog:
/Zi can be enabled in C++ --> General --> Debug Information Format
/DEBUG can be enabled in Linker --> Debugging --> Generate Debug Info
If you want to use the debugger to view the disassembly, you can place a __debugbreak() intrinsic call right before the code which you want to view.
If you're writing straight assembly, you can just use INT 3. When you place a breakpoint using the debugger, it actually changes the code to that (0xCC in binary) so the debugger will get called when it's executed.
You can also call one of the functions that do that for you like zr suggested. The Windows one is DbgBreakPoint(). If you disassemble it, you could easily see it's nothing but INT 3.
These used to be methods of causing breakponts:
_asm
{
int 3
}
or
_asm
{
_emit 0xcc
}
or was it
_emit 0xcc
I'm not sure of the syntax (it's been a while) but hopefully something can be made of it.
I am trying to optimize a lot of multiplications and pointer arithmetics and would like to see what the compiler does underneath when I put in optimization flags.
--Edit--
How to restrict it to a specific function or a code block?
--Edit_2--
How to let gcc generate a less verbose assembly-code?
Add -S switch to your command line.
Edit: Do not forget that it will place the assembly to the files you specified under -o switch.
How to restrict it to a specific function or a code block?
Put that function in a separate source file (and use a different command-line parameter for that one source file).
You could also run that program in a debugger like gdb and use a disassembly view. In gdb you could use the command disass/m to view the assembly mixed with the C code on the current location.
You could stop you program at a breakpoint in the Visual Studio debugger and do "show assembly" and even step through it one instruction at a time.