Breakpoints are broken when compiling with /d1trimfile flag
0.9.21 ALPHA 7be1faaa has regressed issue #364.
Breakpoints are not working when using the /d1trimfile flag of Microsoft (R) C/C++ Optimizing Compiler Version 19.33.31630 for x64.
I do not have permission to reopen that issue, so made this.
Can you try this again on the top of master? I am testing with /d1trimfile locally and it seems to work on my end. What exactly are you seeing?
OK, leave it with me and I will test and try and make a simplified reproduction. Thanks
Hi Ryan,
I tried it on master and see the same issue. I set breakpoints but they are not hit at all, the program just runs. I managed to make a simple case to reproduce the issue and found that commit bfe90f5906a9394ae4bb88b324337f1bf637341e introduced it.
Maybe the full paths are important so this is where I have these files:
The Source: C:\ADAM\CODE\C++\raddebugger_breakpoints\develop\code\app_win32.cpp
/*
Minimal breakpoint repro
Git Bisect
Good: b28b7307888a7d7fec09f6daa40158d306f6cf40
Bad: bfe90f5906a9394ae4bb88b324337f1bf637341e
*/
#include <stdio.h>
int main(int ArgCount, char **Args)
{
printf(__FILE__);
printf("\n");
printf(__FILE__);
printf("\n");
printf(__FILE__);
printf("\n"); // Put a breakpoint here
return 0;
}
The Build: C:\ADAM\CODE\C++\raddebugger_breakpoints\develop\code\build.bat
@echo off
set CompilerFlags=/nologo /Od /Z7 /FC
rem Uncomment the following line to cause RadDebugger to fail to hit breakpoints
set CompilerFlags=%CompilerFlags% /d1trimfile:%CD%\
rem Maybe the path is important as it has '+' characters in it. The %CD% value I have here is:
rem C:\ADAM\CODE\C++\raddebugger_breakpoints\develop\code
rem RadDebugger FilePathMap is set to this:
rem Source: C:/ADAM/CODE/C++/raddebugger_breakpoints/build
rem Destination: C:/ADAM/CODE/C++/raddebugger_breakpoints/develop/code
set BuildFolder=..\..\build
IF NOT exist %BuildFolder% mkdir %BuildFolder%
SET ERRORCOUNT=0
pushd %BuildFolder%
rem It seems I have to delete the pdb, otherwise toggling the Flags above is not sufficient to reproduce
del *.pdb
cl %CompilerFlags% ..\develop\code\app_win32.cpp /link /incremental:no
IF %ERRORLEVEL% NEQ 0 ( SET /A ERRORCOUNT=ERRORCOUNT+1 )
popd
IF %ERRORCOUNT% NEQ 0 (
echo Errors: %ERRORCOUNT%
) ELSE (
echo Success
)
Probably irrelevant, but for completeness, I also have this bat file just for my editor: C:\ADAM\CODE\C++\raddebugger_breakpoints\build.bat
@echo off
rem NOTE: This is just a thunk because my editor is configured to run a build.bat at this location
rem I want the actual build in source control which this is not
pushd .\develop\code
build.bat %*
popd
For a while I thought it could be to do with the flags /Fm or /PDB, which I'm setting for hot reloading but ruled them out.
I hope that allows you to reproduce it!
Tried the same code on 4c32238b382729c65dc57147882c7e9e7efa401e and now the breakpoint is not hit on the first run after a recompile, but it is on following runs.
Okay I think this is caused by the casing of your file paths. If the debugger is not viewing the same paths (using exactly the same case) that are produced in your PDB, then the debugger will incorrectly disqualify those PDBs as being needed for breakpoint resolution. I have this on my list to fix.
Can you try this again after 1ffd662?
Thanks for looking into it, but unfortunately with 1ffd662 I see the same as 4c32238. It only hits the breakpoints from the second run after a recompile. then it hits them fine until I recompile. Same with efb4731a
I think the slashes were auto altered in the File Path Map. It is now this:
(It was originally set by selecting the file from the Find Alternative prompt when not set to anything and doing a Step Into)