WebFreak001 / code-debug

Native debugging for VSCode
The Unlicense
409 stars 115 forks source link

F10(step over) end of main function, 'crtexe.c' The editor could not be opened because the file was not found. #412

Closed Raduq91 closed 9 months ago

Raduq91 commented 9 months ago

How to fix this issue?

GNU gdb (GDB) 10.2; TDM-GCC-64 version 10.3.0; vscodium 1.85.2; win 10 x64

er

GitMensch commented 9 months ago

There's nothing to fix here - you step out of main and therefore into the crt. skip file won't help you here as this is only about not stepping into something, and you may even want to debug crtexe.c.

If you want to get rid of this (not using any stepping at the end of main would be easier) then you can either have that C file (actually it could be an empty one with a plain comment "don't step here") or possibly strip debug information from the MinGW runtime or use an auto command to create a silent breakpoint at the return address of your main, then do a continue there...

Feel free to note something here which is useful in your case, but even than - this is MinGW specific and not related to this extension.

eulerbaby123 commented 1 week ago

so, if have any method to solve this problem permanently?

Raduq91 commented 1 week ago

so, if have any method to solve this problem permanently?

I switched a long time ago to msvc and CodeLLDB (vadimcn). I changed some settings to the extension, I don't remember if it had no issues before the changed settings. In CodeLLDB settings checked the option Supress VSCode's messages about missing source files (when debug info refers to files not available on the local machine) and added some init commands(found info in the internet and chatgpt help I think): image

No issues at printf, when reached the end of the main function I have to press F10(step over)4 times before debugger exits.

(as additional info, I have msvc portable, I used some tool from github[https://gist.github.com/CrendKing/154abfa33200ef1cda38ddd61f4d414b] to download, and I think I used .cmd info from the tool, and I use this to start vscodium:



set ROOT=%~dp0\msvc\

set MSVC_VERSION=14.39.33519
set MSVC_HOST=Hostx64
set MSVC_ARCH=x64
set SDK_VERSION=10.0.22621.0
set SDK_ARCH=x64

set MSVC_ROOT=%ROOT%VC\Tools\MSVC\%MSVC_VERSION%
set SDK_INCLUDE=%ROOT%Windows Kits\10\Include\%SDK_VERSION%
set SDK_LIBS=%ROOT%Windows Kits\10\Lib\%SDK_VERSION%

set VCToolsInstallDir=%MSVC_ROOT%\
set PATH=%~dp0\LLVM-18.1.0-win64\bin\;%~dp0\gdb-15.2\bin;%MSVC_ROOT%\bin\%MSVC_HOST%\%MSVC_ARCH%;%ROOT%Windows Kits\10\bin\%SDK_VERSION%\%SDK_ARCH%;%ROOT%Windows Kits\10\bin\%SDK_VERSION%\%SDK_ARCH%\ucrt;%PATH%
set INCLUDE=%MSVC_ROOT%\include;%SDK_INCLUDE%\ucrt;%SDK_INCLUDE%\shared;%SDK_INCLUDE%\um;%SDK_INCLUDE%\winrt;%SDK_INCLUDE%\cppwinrt
set LIB=%MSVC_ROOT%\lib\%MSVC_ARCH%;%SDK_LIBS%\ucrt\%SDK_ARCH%;%SDK_LIBS%\um\%SDK_ARCH%
set "IFCPATH=%MSVC_ROOT%\ifc\x64

REM WDK
SET LIB=%LIB%;%ROOT%Windows Kits\10\Lib\wdf\kmdf\x64;%ROOT%Windows Kits\10\Lib\wdf\umdf\x64;%SDK_LIBS%\WDK_\um\%SDK_ARCH%;%SDK_LIBS%\WDK_\km\%SDK_ARCH%
SET INCLUDE=%INCLUDE%;%ROOT%Windows Kits\10\Include\wdf\kmdf;%ROOT%Windows Kits\10\Include\wdf\umdf;%SDK_INCLUDE%\WDK_\km;%SDK_INCLUDE%\WDK_\um;%SDK_INCLUDE%\WDK_\shared

vscodium\vscodium.exe
)
Raduq91 commented 4 days ago

so, if have any method to solve this problem permanently?

I approached the problem again(I used msvc), I used CodeLLDB and in the extension settings InitCommands section I added this for printf issue, it does not enter into it: target stop-hook add --one-liner "script if lldb.frame.GetLineEntry().GetFileSpec().GetFilename()=='stdio.h' : lldb.debugger.HandleCommand('thread step-out')"

And same for issue with entering into exe_common.inl after main returns: target stop-hook add --one-liner "script if lldb.frame.GetLineEntry().GetFileSpec().GetFilename()=='exe_common.inl' : lldb.debugger.HandleCommand('thread step-out')"

Other mention: No printf issue with VScodium Version: 1.95.2 and MSVC_VERSION=14.41.34120 (I think maybe it is because of newer msvc)


Tested TDM GCC with lldb, modified command above with crtexe.c instead of stdio.h avoid stepping into printf. LLDB step does not work correctly.


Tested LLVM-18.1.8-win64 with LLDB, exe_common.inl issue as above, no printf issue, stepping works correctly. Local variables from left panel disappear when in twoSum for loop.


LLVM_MINGW64\bin>c++ --version
clang version 18.1.1 (https://github.com/llvm/llvm-project.git dba2a75e9c7ef81fe84774ba5eee5e67e01d801a)
Target: x86_64-w64-windows-gnu
Thread model: posix
(I don't remember exactly, probably I got this from https://github.com/mstorsjo/llvm-mingw)

built with > c++ -g  test.cpp -lstdc++ -o test

LLDB steps correctly, Local variables from left panel are visible in for loop, no printf issue, it enters crtexe.c after main return workaround with: lldb.frame.GetLineEntry().GetFileSpec().GetFilename()=='crtexe.c' : lldb.debugger.HandleCommand('thread step-out')"