eranif / wxdap Goto Github PK

I cannot find out how to enable the library to capture/intercept exceptions to cause a ‘stopped’ event to be fired. If I have missed something could you please let me know how I can enable/setup the library so it can capture/intercept exceptions.

If I have read the protocol the function to setup exception capture/intercept is "SetExceptionBreakpointsRequest".

The reason I am after this is that on the MacOS C::B crashes when performing certain "things" (there are a number of logged tickets for MacOS crashes over the years that have not been fixed). I find the easiest way to try find where the issue is is to case the crash and if the debugger can stop and show the call stack it will narrow the area(s) to look at. "Try" in the previous sentence if everything works correctly.

I may have missed something or may be looking at this in the wrong way, but here goes:

I can only see in the DAP code a m_client.Reset() function that you can use to stop the debugger (not pause), but it does not generate any event to indicate that the debuggee has stopped or not.

I was hoping the process was like the startup where the following process occurs:
-> send m_client.Launch()
<- receive the wxEVT_DAP_LAUNCH_RESPONSE event
Like the following:
-> send m_client.StopDebugging() or use the existing m_client.Reset()
<- receive the wxEVT_DAP_TERMINATED_EVENT event or a new event

At this point in time, which may change, that the OnTerminated(...) function would contain the GUI cleanup code for any debugee termination, but at the moment I need to have to duplicate it in the stopdebugging code that is hooked up to the sop gui bitton and also in the OnTerminated() function unless I create yet another function.

So What do you see as the correct way kill the debuggee effectively from a wxWidget stop debugging button?

BTW: Do you want these type of issues/questions in this repo as an issue or should I use the CodeLite forum or if you enable discussions for this github repo then they could be don in teh discussion area or is there some other way?

gdb server using the DAP protocol (Debug Adapter Protocol)

Is it really ? I ask because I'm a Vim user and I'm searching for a way to use termdebug with DAP.

Termdebug can use any server that implements the GDB/MI interface so if yours can I will use it right away.

As indicated in issue #2 you had issues with the path in the setBreakpoints request.

I have tried the following combinations with the lldb-vscode.exe and unless I specify just main.cpp the the response is I get "verified": false in the response:

• "D:\Andrew_Development\Z_Testing_Apps\Clang_Multi_File_Test\main.cpp"
• "/D/Andrew_Development/Z_Testing_Apps/Clang_Multi_File_Test/main.cpp"
• "/Andrew_Development/Z_Testing_Apps/Clang_Multi_File_Test/main.cpp"
• "D:/Andrew_Development/Z_Testing_Apps/Clang_Multi_File_Test/main.cpp"
• "D:\Andrew_Development\Z_Testing_Apps\Clang_Multi_File_Test/main.cpp"

I am going around in circles on this and think I have covered all of the combinations and have not successfully got an absolute path to work.

Can you let me know if you have gotten an absolute path in the setBreakpoints request working? If you have can I please get an example of the path you use and can you also let me know which lldb-vscode.exe you are using and from MSYS2 CLANG64 or LLVM or some other one.

I have not tried the initialize request pathFormat set to 'uri', but if you have not solved the path I will give it a go.

The breakpoints work with a line number starting offset of 1.
The OnStopped(DAPEvent& event) when a breakpoint is hit has the event line number starting with an offset of 0.
The OnStackTrace(DAPEvent& event) I have not looked at it yet.

This seems a bit strange that there is a difference in the line starting offsets. I would have expected it to be 0 or 1, but not both.

Is this correct or have I missed something?
Are there any other inconsistencies?

I am thinking it may be an idea to create an readme some sort to include some of the issues and results like this and the previous issue to allow other devs read it instead of going through all of the issues. This will only be usefull if there are other projects that will use the library otherwise it will be a waste of time. I do not know if there are other IDE/debuggers that use wxWidgets and therefore would find the DLL useful.

When building on the Mac the <tr1/memory file cannot be found. If you change the include to it builds.

Info on this and discussions on it can be seen in the following issue:
cuberite/cuberite#424

I have also tested the changes on Windows with MSYS2 mingw64 and the code builds.

On Windows the workspace builds okay.

On WSL2 using Ubuntu and GCC 11.1 or Xubuntu 20.04 and GCC 11.1 I get the following error when I try to build via the wxdap-linux.workspace:
/bin/sh: 1: cd: can't cd to build-debug
=== build completed successfully (0 errors, 0 warnings) ===

On Linus should I be using using the workspace or cmake or make?

The reason I am trying to build on Linux is that when I try to build the DLL using the linux C::B project I am working on I get the error below and I want to check if I get the same error with the CodeLite workspace.

-------------- Build: Debugger WXDAP in Debugger WXDAP DLL unix (compiler: GNU GCC Compiler)---------------

g++ -Wall -std=gnu++17 -g -O0 -ggdb -fPIC -isystem/usr/lib/x86_64-linux-gnu/wx/include/gtk3-unicode-3.0 -isystem/usr/include/wx-3.0 -D_FILE_OFFSET_BITS=64 -DWXUSINGDLL -D__WXGTK__ -pthread -DBUILDING_PLUGIN -I. -I/mnt/d/Andrew_Development/Work_Installers/CodeBLocks_Private_Experimental/src/include -c /mnt/d/Andrew_Development/Work_Installers/CodeBLocks_Private_Experimental/src/plugins/contrib-wip/DebugAdapterProtocol/dap.cpp -o /mnt/d/Andrew_Development/Work_Installers/CodeBLocks_Private_Experimental/src/.objs31_64/debugger_WXDAP/dap.o

/mnt/d/Andrew_Development/Work_Installers/CodeBLocks_Private_Experimental/src/plugins/contrib-wip/DebugAdapterProtocol/dap.cpp: In static member function ‘static dap::ObjGenerator& dap::ObjGenerator::Get()’:
/mnt/d/Andrew_Development/Work_Installers/CodeBLocks_Private_Experimental/src/plugins/contrib-wip/DebugAdapterProtocol/dap.cpp:87:25: error: use of deleted function ‘dap::ObjGenerator::ObjGenerator()’
   87 |     static ObjGenerator generator;
      |                         ^~~~~~~~~