Thanks for your build Deepak, it starts without any crashes.
However, the implementation is lacking, and I suspect that making it work with any existing IDE that uses GDB/MI will take a lot of effort.
Few comments:
On Windows, I use some extra normal commands that have no counter part in the MI, such as “set new-console on” (which creates a new CMD.EXE and redirects all the application’s std[in|err|out]), ofc, this does not work
The replies from lldb-mi, are a bit different from gdb, for example, consider this interaction between codelite (the IDE) and lldb-mi:
Using gdbinit file: C:\Users\PC\AppData\Local\Temp\codelite_gdbinit.txt
Current working dir: D:\src\TestArea\wxCrafterTester
Launching gdb from : ./Debug
Starting debugger : C:\Users\PC\Desktop\MinSizeRel\lldb-mi.exe --command=“C:\Users\PC\AppData\Local\Temp\codelite_gdbinit.txt” --interpreter=mi “./wxCrafterTester”
00000001-break-insert -f -t main
00000002-enable-pretty-printing
Debug session started successfully!
00000003-exec-arguments
00000004-exec-run
lldb-mi>>1^error,msg=“Command ‘break-insert’. Breakpoint ‘main’ invalid”
1^error,msg=“Command ‘break-insert’. Breakpoint ‘main’ invalid”
Command: 00000001: -break-insert
According to the docs, it can accept function name (its sole purpose here is to place a temporary breakpoint at ‘main’ (hence, the “-t”) ). It seems like lldb-mi does not expect a function name but rather a location? (did not try that)
Also, the reply from lldb-mi is different:
codelite prepends a transaction ID (8 digits number with fixed length) for each command it sends over to gdb, it is expecting gdb/lldb-mi to reply with these exact 8 digits (including all padding zeros)
this is not the case here (lldb-mi replied with ‘1’ instead of ‘00000001’)
After changing codelite’s gdb settings (i.e. disabled the option to temporarily break at main) I hit another obstacle: I can not place a breakpoint:
00000005-break-insert -f "“D:/src/TestArea/wxCrafterTester/MainFrame.cpp:15"”
…
and lldb-mi replied with:
lldb-mi>>MI: Error: Command Args. Validation failed. Not all arguments or options were recognized: "“D:/src/TestArea/wxCrafterTester/MainFrame.cpp:15"”
MI: Error: Command Args. Validation failed. Not all arguments or options were recognized: "“D:/src/TestArea/wxCrafterTester/MainFrame.cpp:15"”
lldb-mi>>5^error,msg="Command ‘break-insert’. Command Args. Validation failed. Not all arguments or options were recognized: ““D:/src/TestArea/wxCrafterTester/MainFrame.cpp:15"””
5^error,msg="Command ‘break-insert’. Command Args. Validation failed. Not all arguments or options were recognized: ““D:/src/TestArea/wxCrafterTester/MainFrame.cpp:15"””
At first I thought its because of the volume (“D:”) part of the file name, so I changed the settings to send file name without full path, same error occured …
Also, it seems that when lldb-mi hits the first error it simply hangs ( I don’t see my application being launched )
Some more observations:
Commands that are not supported (and used by codelite IDE):
// -exec-arguments
00000010-exec-arguments 1
lldb-mi>>11^error,msg=“Driver. Received command ‘00000011-exec-arguments’. It was not handled. Command ‘exec-arguments’ not in Command Factory”
// -enable-pretty-printing
00000010-enable-pretty-printing
lldb-mi>>10^done,supported=“0”
This was all tested on Windows 7, 64bit.
Trying to debug an executable built with g+±4.8.1 32bit, (MinGW, no MSYS)
Thanks for you work,
Eran
We’ll see if we can repo this sort of thing and have a look at it. We use it on windows too so the volume being part of the file name shouldn’t really matter. Yup, lots of commands still to write. At the moment though you can certainly use this frontend and it’s usable on Eclipse, for remote targets anyway. Breakpoints, single stepping, local variables, stack traces are all there and supported. Obviously there will be issues given we’re only testing on Eclipse. As every ‘standard’ implementer knows, the only standard thing about all the implementations is that they are guaranteed to all be used in subtly different ways