lldb-tools/lldb-mi

LLDB's machine interface driver

lldb-mi's Issues

lldb-mi hangs on M1 macOS when creating variable

Environment

• OS and version: macOS Monterey 12.4
• VS Code: 1.68.0
• C/C++ extension: 1.11.0
• OS and version of remote machine (if applicable): no
• GDB / LLDB version: 13.0.1

Bug Summary and Steps to Reproduce

Bug Summary: When debugging some code(for example, leveldb test code), sometimes the debug can't go on.

Steps to reproduce:

1. Clone leveldb and add main.cpp

4. Debug this executable, when entering DB::Open:

then I was stuck in `*dbptr = nullptr;` where there's 4 lldb-mi process and in the right panel(variable),there is a circle spinning.

Debugger Configurations

{
  "version": "0.2.0",
  "configurations": [
    {
      "type": "cppdbg",
      "request": "launch",
      "name": "Debug main test",
      "program": "${workspaceFolder}/build/main_test",
      "args": [],
      "MIMode": "lldb",
      "cwd": "${workspaceFolder}",
      "MIMode": "lldb",
      "miDebuggerPath": "/Users/fangliming/Documents/GitHub/collections/lldb-mi/src/lldb-mi",
    }
  ]

lldb-mi version

Debugger Logs

log link

Additional Information

• lldb-mi won't exit when stop debugging.
• CodeLLDB extension works fine on my Mac.

outro

From the logs, it looks like the debugger is hanging on creating the variable edit.

-1034-var-create - - "edit" --thread 1 --frame 0

Why it is hanging on creating the VersionEdit edit variable.

• microsoft/vscode-cpptools#9488

lldb-mi exits launching my application with SIGKILL

I'm trying to debug my application using VS-Code, with their bundled lldb-mi (will build from current source here in a moment)

If I create a small test application, lldb-mi works fine, but if I try to debug my real application, which is large, lldb-mi dies right after it logs loading symbols for the app. When I use regular lldb (supplied by XCode), everything works as expected.

LLDB Machine Interface Driver (MI) All rights reserved
Version: 1.0.0.9
Version: GNU gdb (GDB) 7.4 

lldb-1300.0.42.3
Swift version 5.5.2-dev

Output from lldb-mi when it dies (after manually doing a 'run')

(gdb)
=library-loaded,id="/usr/lib/dyld",target-name="/usr/lib/dyld",host-name="/usr/lib/dyld",symbols-loaded="0",loaded_addr="0x00000001041cc000",size="638976"
=library-loaded,id="/Users/jmt/FGFS/fg-work2/build/src/Main/RelWithDebInfo/fgfs.app/Contents/MacOS/fgfs",target-name="/Users/jmt/FGFS/fg-work2/build/src/Main/RelWithDebInfo/fgfs.app/Contents/MacOS/fgfs",host-name="/Users/jmt/FGFS/fg-work2/build/src/Main/RelWithDebInfo/fgfs.app/Contents/MacOS/fgfs",symbols-loaded="0",loaded_addr="0x0000000100000000",size="46628864"
*running,thread-id="all"
(gdb)
Killed: 9

I suspect this is a configuration problem but I have no clue how to debug it further: can you suggest anything I can set / log / try to isolate where the real problem might be? Aside from trying lldb-mi from this Git which I will do in a moment.

Publish a release for lldb-mi

Hi,
I wonder if there is any plan for publishing releases for lldb-mi?

Failed to build within Ubuntu 20.04 lldb 10.0 & cmake 3.16.3

After cloned the repository, the command 'cmake .' raised a error illustrated below.

Environment:
Ubuntu 20.04 focal on WSL2
lldb 10.0 installed by apt install
clang 10.0 installed by apt install
cmake 3.16.3 installed by apt install

lldb-mi hangs on MacOS

When I run lldb-mi on MacOS it hangs. Here is the console output:

(gdb)
-file-exec-and-symbols "test"
^done
(gdb)
=library-loaded,id="[...]/test",target-name="[...]/test",host-name="[...]/test",symbols-loaded="0",loaded_addr="-",size="23838720"
r test
~"Process 34501 launched: '[...]/test' (x86_64)\n"
^done
(gdb)
=thread-created,id="1",group-id="i1"
=thread-selected,id="1"
(gdb)
=library-unloaded,id="[...]/test",target-name="[...]/test",host-name="[...]/test"
(gdb)
=library-loaded,id="/usr/lib/dyld",target-name="/usr/lib/dyld",host-name="/usr/lib/dyld",symbols-loaded="0",loaded_addr="0x0000000101eb4000",size="442368"
=library-loaded,id="[...]/test",target-name="[...]/test",host-name="[...]/test",symbols-loaded="0",loaded_addr="0x0000000100000000",size="23838720"
*running,thread-id="all"
(gdb)

Here is a sample of the process obtained via Activity Monitor: https://gist.github.com/busjaeger/c5653cd197fb0c82d9ca79bf95f521f0

If I enter r again, and answer n to killing the running process, the process executes and completes successfully.

r
There is a running process, kill it and restart?: [Y/n] n
^done
(gdb)
(gdb)
=library-loaded,id="[...]/compression/zstd/lib/libzstd.1.3.4.dylib",target-name="[...]/compression/zstd/lib/libzstd.1.3.4.dylib",host-name="[...]/compression/zstd/lib/libzstd.1.3.4.dylib",symbols-loaded="1",symbols-path="[...]/compression/zstd/lib/libzstd.1.3.4.dylib.dSYM/Contents/Resources/DWARF/libzstd.1.3.4.dylib",loaded_addr="0x0000000102154000",size="720896"
=library-loaded,id="/usr/lib/libz.1.dylib",target-name="/usr/lib/libz.1.dylib",host-name="/usr/lib/libz.1.dylib",symbols-loaded="0",loaded_addr="0x00007ff8261d9000",size="77824"
=library-loaded,id="/usr/lib/libSystem.B.dylib",target-name="/usr/lib/libSystem.B.dylib",host-name="/usr/lib/libSystem.B.dylib",symbols-loaded="0",loaded_addr="0x00007ff8262b9000",size="8192"
=library-loaded,id="/usr/lib/system/libcache.dylib",target-name="/usr/lib/system/libcache.dylib",host-name="/usr/lib/system/libcache.dylib",symbols-loaded="0",loaded_addr="0x00007ff8262b4000",size="20480"
=library-loaded,id="/usr/lib/system/libcommonCrypto.dylib",target-name="/usr/lib/system/libcommonCrypto.dylib",host-name="/usr/lib/system/libcommonCrypto.dylib",symbols-loaded="0",loaded_addr="0x00007ff826270000",size="49152"
=library-loaded,id="/usr/lib/system/libcompiler_rt.dylib",target-name="/usr/lib/system/libcompiler_rt.dylib",host-name="/usr/lib/system/libcompiler_rt.dylib",symbols-loaded="0",loaded_addr="0x00007ff826299000",size="32768"
=library-loaded,id="/usr/lib/system/libcopyfile.dylib",target-name="/usr/lib/system/libcopyfile.dylib",host-name="/usr/lib/system/libcopyfile.dylib",symbols-loaded="0",loaded_addr="0x00007ff82628f000",size="40960"
=library-loaded,id="/usr/lib/system/libcorecrypto.dylib",target-name="/usr/lib/system/libcorecrypto.dylib",host-name="/usr/lib/system/libcorecrypto.dylib",symbols-loaded="0",loaded_addr="0x00007ff81b264000",size="598016"
=library-loaded,id="/usr/lib/system/libdispatch.dylib",target-name="/usr/lib/system/libdispatch.dylib",host-name="/usr/lib/system/libdispatch.dylib",symbols-loaded="0",loaded_addr="0x00007ff81b322000",size="290816"
=library-loaded,id="/usr/lib/system/libdyld.dylib",target-name="/usr/lib/system/libdyld.dylib",host-name="/usr/lib/system/libdyld.dylib",symbols-loaded="0",loaded_addr="0x00007ff81b4e6000",size="49152"
=library-loaded,id="/usr/lib/system/libkeymgr.dylib",target-name="/usr/lib/system/libkeymgr.dylib",host-name="/usr/lib/system/libkeymgr.dylib",symbols-loaded="0",loaded_addr="0x00007ff8262ab000",size="4096"
=library-loaded,id="/usr/lib/system/libmacho.dylib",target-name="/usr/lib/system/libmacho.dylib",host-name="/usr/lib/system/libmacho.dylib",symbols-loaded="0",loaded_addr="0x00007ff82624e000",size="24576"
=library-loaded,id="/usr/lib/system/libquarantine.dylib",target-name="/usr/lib/system/libquarantine.dylib",host-name="/usr/lib/system/libquarantine.dylib",symbols-loaded="0",loaded_addr="0x00007ff8258cd000",size="12288"
=library-loaded,id="/usr/lib/system/libremovefile.dylib",target-name="/usr/lib/system/libremovefile.dylib",host-name="/usr/lib/system/libremovefile.dylib",symbols-loaded="0",loaded_addr="0x00007ff8262a9000",size="8192"
=library-loaded,id="/usr/lib/system/libsystem_asl.dylib",target-name="/usr/lib/system/libsystem_asl.dylib",host-name="/usr/lib/system/libsystem_asl.dylib",symbols-loaded="0",loaded_addr="0x00007ff820460000",size="94208"
=library-loaded,id="/usr/lib/system/libsystem_blocks.dylib",target-name="/usr/lib/system/libsystem_blocks.dylib",host-name="/usr/lib/system/libsystem_blocks.dylib",symbols-loaded="0",loaded_addr="0x00007ff81b20d000",size="8192"
=library-loaded,id="/usr/lib/system/libsystem_c.dylib",target-name="/usr/lib/system/libsystem_c.dylib",host-name="/usr/lib/system/libsystem_c.dylib",symbols-loaded="0",loaded_addr="0x00007ff81b3aa000",size="561152"
=library-loaded,id="/usr/lib/system/libsystem_collections.dylib",target-name="/usr/lib/system/libsystem_collections.dylib",host-name="/usr/lib/system/libsystem_collections.dylib",symbols-loaded="0",loaded_addr="0x00007ff8262a1000",size="20480"
=library-loaded,id="/usr/lib/system/libsystem_configuration.dylib",target-name="/usr/lib/system/libsystem_configuration.dylib",host-name="/usr/lib/system/libsystem_configuration.dylib",symbols-loaded="0",loaded_addr="0x00007ff824b7a000",size="16384"
=library-loaded,id="/usr/lib/system/libsystem_containermanager.dylib",target-name="/usr/lib/system/libsystem_containermanager.dylib",host-name="/usr/lib/system/libsystem_containermanager.dylib",symbols-loaded="0",loaded_addr="0x00007ff823e26000",size="118784"
=library-loaded,id="/usr/lib/system/libsystem_coreservices.dylib",target-name="/usr/lib/system/libsystem_coreservices.dylib",host-name="/usr/lib/system/libsystem_coreservices.dylib",symbols-loaded="0",loaded_addr="0x00007ff825f87000",size="20480"
=library-loaded,id="/usr/lib/system/libsystem_darwin.dylib",target-name="/usr/lib/system/libsystem_darwin.dylib",host-name="/usr/lib/system/libsystem_darwin.dylib",symbols-loaded="0",loaded_addr="0x00007ff81db09000",size="40960"
=library-loaded,id="/usr/lib/system/libsystem_dnssd.dylib",target-name="/usr/lib/system/libsystem_dnssd.dylib",host-name="/usr/lib/system/libsystem_dnssd.dylib",symbols-loaded="0",loaded_addr="0x00007ff8262ac000",size="32768"
=library-loaded,id="/usr/lib/system/libsystem_featureflags.dylib",target-name="/usr/lib/system/libsystem_featureflags.dylib",host-name="/usr/lib/system/libsystem_featureflags.dylib",symbols-loaded="0",loaded_addr="0x00007ff81b3a7000",size="12288"
=library-loaded,id="/usr/lib/system/libsystem_info.dylib",target-name="/usr/lib/system/libsystem_info.dylib",host-name="/usr/lib/system/libsystem_info.dylib",symbols-loaded="0",loaded_addr="0x00007ff81b4fc000",size="176128"
=library-loaded,id="/usr/lib/system/libsystem_m.dylib",target-name="/usr/lib/system/libsystem_m.dylib",host-name="/usr/lib/system/libsystem_m.dylib",symbols-loaded="0",loaded_addr="0x00007ff8261ec000",size="397312"
=library-loaded,id="/usr/lib/system/libsystem_malloc.dylib",target-name="/usr/lib/system/libsystem_malloc.dylib",host-name="/usr/lib/system/libsystem_malloc.dylib",symbols-loaded="0",loaded_addr="0x00007ff81b2f6000",size="180224"
=library-loaded,id="/usr/lib/system/libsystem_networkextension.dylib",target-name="/usr/lib/system/libsystem_networkextension.dylib",host-name="/usr/lib/system/libsystem_networkextension.dylib",symbols-loaded="0",loaded_addr="0x00007ff8203fb000",size="94208"
=library-loaded,id="/usr/lib/system/libsystem_notify.dylib",target-name="/usr/lib/system/libsystem_notify.dylib",host-name="/usr/lib/system/libsystem_notify.dylib",symbols-loaded="0",loaded_addr="0x00007ff81df2f000",size="61440"
=library-loaded,id="/usr/lib/system/libsystem_product_info_filter.dylib",target-name="/usr/lib/system/libsystem_product_info_filter.dylib",host-name="/usr/lib/system/libsystem_product_info_filter.dylib",symbols-loaded="1",symbols-path="",loaded_addr="0x00007ff82c517000",size="4096"
=library-loaded,id="/usr/lib/system/libsystem_sandbox.dylib",target-name="/usr/lib/system/libsystem_sandbox.dylib",host-name="/usr/lib/system/libsystem_sandbox.dylib",symbols-loaded="0",loaded_addr="0x00007ff824b7e000",size="24576"
=library-loaded,id="/usr/lib/system/libsystem_secinit.dylib",target-name="/usr/lib/system/libsystem_secinit.dylib",host-name="/usr/lib/system/libsystem_secinit.dylib",symbols-loaded="0",loaded_addr="0x00007ff8262a6000",size="12288"
=library-loaded,id="/usr/lib/system/libsystem_kernel.dylib",target-name="/usr/lib/system/libsystem_kernel.dylib",host-name="/usr/lib/system/libsystem_kernel.dylib",symbols-loaded="0",loaded_addr="0x00007ff81b4a2000",size="229376"
=library-loaded,id="/usr/lib/system/libsystem_platform.dylib",target-name="/usr/lib/system/libsystem_platform.dylib",host-name="/usr/lib/system/libsystem_platform.dylib",symbols-loaded="0",loaded_addr="0x00007ff81b4f2000",size="40960"
=library-loaded,id="/usr/lib/system/libsystem_pthread.dylib",target-name="/usr/lib/system/libsystem_pthread.dylib",host-name="/usr/lib/system/libsystem_pthread.dylib",symbols-loaded="0",loaded_addr="0x00007ff81b4da000",size="49152"
=library-loaded,id="/usr/lib/system/libsystem_symptoms.dylib",target-name="/usr/lib/system/libsystem_symptoms.dylib",host-name="/usr/lib/system/libsystem_symptoms.dylib",symbols-loaded="0",loaded_addr="0x00007ff821ca8000",size="32768"
=library-loaded,id="/usr/lib/system/libsystem_trace.dylib",target-name="/usr/lib/system/libsystem_trace.dylib",host-name="/usr/lib/system/libsystem_trace.dylib",symbols-loaded="0",loaded_addr="0x00007ff81b24b000",size="102400"
=library-loaded,id="/usr/lib/system/libunwind.dylib",target-name="/usr/lib/system/libunwind.dylib",host-name="/usr/lib/system/libunwind.dylib",symbols-loaded="0",loaded_addr="0x00007ff82627c000",size="45056"
=library-loaded,id="/usr/lib/system/libxpc.dylib",target-name="/usr/lib/system/libxpc.dylib",host-name="/usr/lib/system/libxpc.dylib",symbols-loaded="0",loaded_addr="0x00007ff81b20f000",size="245760"
=library-loaded,id="/usr/lib/libc++abi.dylib",target-name="/usr/lib/libc++abi.dylib",host-name="/usr/lib/libc++abi.dylib",symbols-loaded="0",loaded_addr="0x00007ff81b48c000",size="90112"
=library-loaded,id="/usr/lib/libobjc.A.dylib",target-name="/usr/lib/libobjc.A.dylib",host-name="/usr/lib/libobjc.A.dylib",symbols-loaded="0",loaded_addr="0x00007ff81b369000",size="253952"
=library-loaded,id="/usr/lib/liboah.dylib",target-name="/usr/lib/liboah.dylib",host-name="/usr/lib/liboah.dylib",symbols-loaded="0",loaded_addr="0x00007ff826287000",size="32768"
=library-loaded,id="/usr/lib/libc++.1.dylib",target-name="/usr/lib/libc++.1.dylib",host-name="/usr/lib/libc++.1.dylib",symbols-loaded="0",loaded_addr="0x00007ff81b433000",size="364544"
[...]
(gdb)
=thread-exited,id="1",group-id="i1"
=thread-group-exited,id="i1",exit-code="0"
*stopped,reason="exited-normally"
(gdb)

The debugger in Eclipse and VSCode also hang for this executable (I believe due to the same problem). I don't have this problem with simple 'Hello World' executables. I suspect the reason is that this executable loads some dynamic libraries. The stack trace seems to suggest the process is blocked initializing python.

Please let me know if you need more info. Thanks in advance for any pointers!

lldb-mi hangs and starts consuming more and more memory when stopping at certain breakpoints in vscode-cpptools

Hi, I wanted to notify you of several issues that crop up with debugging via the cpptools package for Visual Studio Code, which appear to be caused by an error in lldb-mi.
In summary stopping at (or in some cases near) uninitialized memory.
More details can be found in the following related issues

• microsoft/vscode-cpptools#1899
• microsoft/vscode-cpptools#5805
• microsoft/vscode-cpptools#7240

Kind Regards

Marco

Member variables not updating using var objects

Using lldb-mi in master as of today (also seen with older versions)

Using this sample code:

class MyClass {
public:
int field;
};

int main() {
MyClass obj;
obj.field = 5;
obj.field = 4;
}

In Eclipse, if I step through the code, the value of 'obj.field' is not updated in the views. Looking at the MI traces, it looks like when the -var-create is done on 'obj', correctly but -var-update doesn’t report the change:

Using lldb-mi (macOS):
994,853 30-var-create --thread 1 --frame 0 - * obj
994,856 30^done,name="var0",numchild="1",value="{...}",type="MyClass",thread-id="1",has_more="0"
...
581,399 48-var-update 1 var0
581,403 48^done,changelist=[{name="var0",value="{...}",in_scope="true",type_changed="false",has_more
="0"}]

Using GDB (Linux):
980,932 40-var-create --thread 1 --frame 0 - * obj
980,939 40^done,name="var1",numchild="1",value="{...}",type="MyClass",thread-id="1",has_more="0"
....
749,655 56-var-update 1 var1
749,655 56^done,changelist=[{name="var1.public.field",value="4",in_scope="true",type_changed="false"
,has_more="0"}]

This is a major issue because it makes debugging non-trivial programs almost impossible.

Originating Eclips bug:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=503302
Old llvm bug:
https://bugs.llvm.org/show_bug.cgi?id=32100

`-break-insert` response doesn't respect `target.source-map`

The "fullname" field in the response doesn't contain the mapped path. I've captured both the lldb-mi and gdb commands and traces for comparison. Based on the mapping the /usr/src/hello_world.c source path should be mapped to /home/troy/git/hello_world_c/hello_world.c, but is instead being reported without the mapping (i.e., /usr/src/hello_world.c).

lldb-mi

commands

lldb-mi
settings append target.source-map /usr/src /home/troy/git/hello_world_c
settings show target.source-map
-file-exec-and-symbols hello_world
-break-insert -t -f main

lldb-mi trace

> lldb-mi
Traceback (most recent call last):
  File "<string>", line 1, in <module>
ModuleNotFoundError: No module named 'lldb.embedded_interpreter'
(gdb)
settings append target.source-map /usr/src /home/troy/git/hello_world_c
^done
(gdb)
settings show target.source-map
~"target.source-map (path-map) =\n[0] \"/usr/src\" -> \"/home/troy/git/hello_world_c\"\n\n"
^done
(gdb)
-file-exec-and-symbols hello_world
^done
(gdb)
=library-loaded,id="/home/troy/git/hello_world_exe/hello_world",target-name="/home/troy/git/hello_world_exe/hello_world",host-name="/home/troy/git/hello_world_exe/hello_world",symbols-loaded="0",loaded_addr="-",size="1560"
-break-insert -t -f main
^done,bkpt={number="1",type="breakpoint",disp="del",enabled="y",pending=["main"],times="0",addr="0x000000000000114f",func="main",file="hello_world.c",fullname="/usr/src/hello_world.c",line="8",original-location="main"}
(gdb)
=breakpoint-modified,bkpt={number="1",type="breakpoint",disp="del",enabled="y",pending=["main"],times="0",addr="0x000000000000114f",func="main",file="hello_world.c",fullname="/usr/src/hello_world.c",line="8",original-location="main"}
(gdb)

gdb

commands

gdb -q --interpreter=mi2
-gdb-set substitute-path /usr/src /home/troy/git/hello_world_c
-file-exec-and-symbols hello_world
-break-insert -t -f main

trace

gdb -q --interpreter=mi2
=thread-group-added,id="i1"
(gdb) 
-gdb-set substitute-path /usr/src /home/troy/git/hello_world_c
^done
(gdb) 
-file-exec-and-symbols hello_world
^done
(gdb) 
-break-insert -t -f main
^done,bkpt={number="1",type="breakpoint",disp="del",enabled="y",addr="0x000000000000114f",func="main",file="hello_world.c",fullname="/home/troy/git/hello_world_c/hello_world.c",line="8",thread-groups=["i1"],times="0",original-location="main"}
(gdb)

lldb-mi build fails on linux with "Undefined symbol: llvm::Twine::str() const"

Building llvm-mi on linux with clang 13 sources fails with error "ld.lld: error: undefined symbol: llvm::Twine::str() const"
referenced by MICmdCmdData.cpp
referenced by MICmdCmdSymbol.cpp
referenced by MICmdCmdSymbol.cpp

Error while building this package

Hi team,

I am getting the following errors when I try to build this package. The environment is the latest Mac OS. Can someone help me to debug this issue?

usr/local/Cellar/cmake/3.23.0/bin/cmake -S/Users/randyburrell/Projects/Environments/Rust/lldb-mi -B/Users/randyburrell/Projects/Environments/Rust/lldb-mi/build --check-build-system CMakeFiles/Makefile.cmake 0 /usr/local/Cellar/cmake/3.23.0/bin/cmake -E cmake_progress_start /Users/randyburrell/Projects/Environments/Rust/lldb-mi/build/CMakeFiles /Users/randyburrell/Projects/Environments/Rust/lldb-mi/build//CMakeFiles/progress.marks /Applications/Xcode.app/Contents/Developer/usr/bin/make -f CMakeFiles/Makefile2 all /Applications/Xcode.app/Contents/Developer/usr/bin/make -f src/CMakeFiles/lldb-mi.dir/build.make src/CMakeFiles/lldb-mi.dir/depend cd /Users/randyburrell/Projects/Environments/Rust/lldb-mi/build && /usr/local/Cellar/cmake/3.23.0/bin/cmake -E cmake_depends "Unix Makefiles" /Users/randyburrell/Projects/Environments/Rust/lldb-mi /Users/randyburrell/Projects/Environments/Rust/lldb-mi/src /Users/randyburrell/Projects/Environments/Rust/lldb-mi/build /Users/randyburrell/Projects/Environments/Rust/lldb-mi/build/src /Users/randyburrell/Projects/Environments/Rust/lldb-mi/build/src/CMakeFiles/lldb-mi.dir/DependInfo.cmake --color= /Applications/Xcode.app/Contents/Developer/usr/bin/make -f src/CMakeFiles/lldb-mi.dir/build.make src/CMakeFiles/lldb-mi.dir/build [ 1%] Linking CXX executable lldb-mi cd /Users/randyburrell/Projects/Environments/Rust/lldb-mi/build/src && /usr/local/Cellar/cmake/3.23.0/bin/cmake -E cmake_link_script CMakeFiles/lldb-mi.dir/link.txt --verbose=1 /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++ -fPIC -fvisibility-inlines-hidden -Werror=date-time -Werror=unguarded-availability-new -w -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.3.sdk -mmacosx-version-min=12.2 -Wl,-search_paths_first -Wl,-headerpad_max_install_names -L/usr/local/opt/llvm/lib "CMakeFiles/lldb-mi.dir/MICmdArgContext.cpp.o" "CMakeFiles/lldb-mi.dir/MICmdArgSet.cpp.o" "CMakeFiles/lldb-mi.dir/MICmdArgValBase.cpp.o" "CMakeFiles/lldb-mi.dir/MICmdArgValConsume.cpp.o" "CMakeFiles/lldb-mi.dir/MICmdArgValFile.cpp.o" "CMakeFiles/lldb-mi.dir/MICmdArgValListBase.cpp.o" "CMakeFiles/lldb-mi.dir/MICmdArgValListOfN.cpp.o" "CMakeFiles/lldb-mi.dir/MICmdArgValNumber.cpp.o" "CMakeFiles/lldb-mi.dir/MICmdArgValOptionLong.cpp.o" "CMakeFiles/lldb-mi.dir/MICmdArgValOptionShort.cpp.o" "CMakeFiles/lldb-mi.dir/MICmdArgValPrintValues.cpp.o" "CMakeFiles/lldb-mi.dir/MICmdArgValString.cpp.o" "CMakeFiles/lldb-mi.dir/MICmdArgValText.cpp.o" "CMakeFiles/lldb-mi.dir/MICmdArgValThreadGrp.cpp.o" "CMakeFiles/lldb-mi.dir/MICmdBase.cpp.o" "CMakeFiles/lldb-mi.dir/MICmdCommands.cpp.o" "CMakeFiles/lldb-mi.dir/MICmdCmd.cpp.o" "CMakeFiles/lldb-mi.dir/MICmdCmdBreak.cpp.o" "CMakeFiles/lldb-mi.dir/MICmdCmdData.cpp.o" "CMakeFiles/lldb-mi.dir/MICmdCmdEnviro.cpp.o" "CMakeFiles/lldb-mi.dir/MICmdCmdExec.cpp.o" "CMakeFiles/lldb-mi.dir/MICmdCmdFile.cpp.o" "CMakeFiles/lldb-mi.dir/MICmdCmdGdbInfo.cpp.o" "CMakeFiles/lldb-mi.dir/MICmdCmdGdbSet.cpp.o" "CMakeFiles/lldb-mi.dir/MICmdCmdGdbShow.cpp.o" "CMakeFiles/lldb-mi.dir/MICmdCmdGdbThread.cpp.o" "CMakeFiles/lldb-mi.dir/MICmdCmdMiscellanous.cpp.o" "CMakeFiles/lldb-mi.dir/MICmdCmdStack.cpp.o" "CMakeFiles/lldb-mi.dir/MICmdCmdSupportInfo.cpp.o" "CMakeFiles/lldb-mi.dir/MICmdCmdSupportList.cpp.o" "CMakeFiles/lldb-mi.dir/MICmdCmdSymbol.cpp.o" "CMakeFiles/lldb-mi.dir/MICmdCmdTarget.cpp.o" "CMakeFiles/lldb-mi.dir/MICmdCmdThread.cpp.o" "CMakeFiles/lldb-mi.dir/MICmdCmdTrace.cpp.o" "CMakeFiles/lldb-mi.dir/MICmdCmdVar.cpp.o" "CMakeFiles/lldb-mi.dir/MICmdData.cpp.o" "CMakeFiles/lldb-mi.dir/MICmdFactory.cpp.o" "CMakeFiles/lldb-mi.dir/MICmdInterpreter.cpp.o" "CMakeFiles/lldb-mi.dir/MICmdInvoker.cpp.o" "CMakeFiles/lldb-mi.dir/MICmdMgr.cpp.o" "CMakeFiles/lldb-mi.dir/MICmdMgrSetCmdDeleteCallback.cpp.o" "CMakeFiles/lldb-mi.dir/MICmnBase.cpp.o" "CMakeFiles/lldb-mi.dir/MICmnLLDBBroadcaster.cpp.o" "CMakeFiles/lldb-mi.dir/MICmnLLDBDebugger.cpp.o" "CMakeFiles/lldb-mi.dir/MICmnLLDBDebuggerHandleEvents.cpp.o" "CMakeFiles/lldb-mi.dir/MICmnLLDBDebugSessionInfo.cpp.o" "CMakeFiles/lldb-mi.dir/MICmnLLDBDebugSessionInfoVarObj.cpp.o" "CMakeFiles/lldb-mi.dir/MICmnLLDBProxySBValue.cpp.o" "CMakeFiles/lldb-mi.dir/MICmnLLDBUtilSBValue.cpp.o" "CMakeFiles/lldb-mi.dir/MICmnLog.cpp.o" "CMakeFiles/lldb-mi.dir/MICmnLogMediumFile.cpp.o" "CMakeFiles/lldb-mi.dir/MICmnMIOutOfBandRecord.cpp.o" "CMakeFiles/lldb-mi.dir/MICmnMIResultRecord.cpp.o" "CMakeFiles/lldb-mi.dir/MICmnMIValue.cpp.o" "CMakeFiles/lldb-mi.dir/MICmnMIValueConst.cpp.o" "CMakeFiles/lldb-mi.dir/MICmnMIValueList.cpp.o" "CMakeFiles/lldb-mi.dir/MICmnMIValueResult.cpp.o" "CMakeFiles/lldb-mi.dir/MICmnMIValueTuple.cpp.o" "CMakeFiles/lldb-mi.dir/MICmnResources.cpp.o" "CMakeFiles/lldb-mi.dir/MICmnStreamStderr.cpp.o" "CMakeFiles/lldb-mi.dir/MICmnStreamStdin.cpp.o" "CMakeFiles/lldb-mi.dir/MICmnStreamStdout.cpp.o" "CMakeFiles/lldb-mi.dir/MICmnThreadMgrStd.cpp.o" "CMakeFiles/lldb-mi.dir/MIDriver.cpp.o" "CMakeFiles/lldb-mi.dir/MIDriverBase.cpp.o" "CMakeFiles/lldb-mi.dir/MIDriverMain.cpp.o" "CMakeFiles/lldb-mi.dir/MIDriverMgr.cpp.o" "CMakeFiles/lldb-mi.dir/MIUtilDateTimeStd.cpp.o" "CMakeFiles/lldb-mi.dir/MIUtilDebug.cpp.o" "CMakeFiles/lldb-mi.dir/MIUtilFileStd.cpp.o" "CMakeFiles/lldb-mi.dir/MIUtilMapIdToVariant.cpp.o" "CMakeFiles/lldb-mi.dir/MIUtilString.cpp.o" "CMakeFiles/lldb-mi.dir/MIUtilThreadBaseStd.cpp.o" "CMakeFiles/lldb-mi.dir/MIUtilVariant.cpp.o" -o lldb-mi /usr/local/opt/llvm/lib/liblldb.dylib /usr/local/opt/llvm/lib/libLLVM.dylib Undefined symbols for architecture x86_64: "std::__1::basic_filebuf<char, std::__1::char_traits<char> >::open(char const*, unsigned int)", referenced from: std::__1::basic_ifstream<char, std::__1::char_traits<char> >::basic_ifstream(char const*, unsigned int) in MIDriver.cpp.o "std::__1::basic_filebuf<char, std::__1::char_traits<char> >::basic_filebuf()", referenced from: std::__1::basic_ifstream<char, std::__1::char_traits<char> >::basic_ifstream(char const*, unsigned int) in MIDriver.cpp.o "std::__1::basic_filebuf<char, std::__1::char_traits<char> >::~basic_filebuf()", referenced from: std::__1::basic_ifstream<char, std::__1::char_traits<char> >::basic_ifstream(char const*, unsigned int) in MIDriver.cpp.o std::__1::basic_ifstream<char, std::__1::char_traits<char> >::~basic_ifstream() in MIDriver.cpp.o "std::__1::basic_stringbuf<char, std::__1::char_traits<char>, std::__1::allocator<char> >::str(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&)", referenced from: std::__1::basic_stringbuf<char, std::__1::char_traits<char>, std::__1::allocator<char> >::basic_stringbuf(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, unsigned int) in MIUtilString.cpp.o "VTT for std::__1::basic_ifstream<char, std::__1::char_traits<char> >", referenced from: std::__1::basic_ifstream<char, std::__1::char_traits<char> >::basic_ifstream(char const*, unsigned int) in MIDriver.cpp.o std::__1::basic_ifstream<char, std::__1::char_traits<char> >::~basic_ifstream() in MIDriver.cpp.o "VTT for std::__1::basic_stringstream<char, std::__1::char_traits<char>, std::__1::allocator<char> >", referenced from: std::__1::basic_stringstream<char, std::__1::char_traits<char>, std::__1::allocator<char> >::basic_stringstream(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, unsigned int) in MIUtilString.cpp.o std::__1::basic_stringstream<char, std::__1::char_traits<char>, std::__1::allocator<char> >::~basic_stringstream() in MIUtilString.cpp.o "vtable for std::__1::basic_ifstream<char, std::__1::char_traits<char> >", referenced from: std::__1::basic_ifstream<char, std::__1::char_traits<char> >::basic_ifstream(char const*, unsigned int) in MIDriver.cpp.o NOTE: a missing vtable usually means the first non-inline virtual member function has no definition. "vtable for std::__1::basic_stringbuf<char, std::__1::char_traits<char>, std::__1::allocator<char> >", referenced from: std::__1::basic_stringbuf<char, std::__1::char_traits<char>, std::__1::allocator<char> >::~basic_stringbuf() in MIUtilString.cpp.o std::__1::basic_stringbuf<char, std::__1::char_traits<char>, std::__1::allocator<char> >::basic_stringbuf(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, unsigned int) in MIUtilString.cpp.o NOTE: a missing vtable usually means the first non-inline virtual member function has no definition. "vtable for std::__1::basic_stringstream<char, std::__1::char_traits<char>, std::__1::allocator<char> >", referenced from: std::__1::basic_stringstream<char, std::__1::char_traits<char>, std::__1::allocator<char> >::basic_stringstream(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, unsigned int) in MIUtilString.cpp.o NOTE: a missing vtable usually means the first non-inline virtual member function has no definition. ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) make[2]: *** [src/lldb-mi] Error 1 make[1]: *** [src/CMakeFiles/lldb-mi.dir/all] Error 2 make: *** [all] Error 2

Undefined symbol llvm::itaniumDemangle (missing libLLVMDemangle in cmake)

Using latest master 89945aa (May 4 2021)
cmake version 3.20.5
macOS 11.4
LLVM cloned from git, at 3b4aad1 (Jun 24 2021)
Using cmake command: cmake -DCMAKE_PREFIX_PATH=/foo/git/llvm/build-install -GNinja

If I build lldb-mi against this LLVM repo, I get

Undefined symbols for architecture x86_64:
"llvm::itaniumDemangle(char const*, char*, unsigned long*, int*)", referenced from:
llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) in libLLVMSupport.a(Signals.cpp.o)

Strangely libLLVMDemangle.a is not in the linker command-line.

In src/CMakeLists.txt, I see the use of LLVMBUILD_LIB_DEPS_LLVMSupport which I would expect would include LLVMDemangle but it doesn't seem to.

If I add the library by hand, then it works.

-target_link_libraries(lldb-mi ${lib_lldb} ${lib_llvm} ${llvm_deps})
+target_link_libraries(lldb-mi ${lib_lldb} ${lib_llvm} ${llvm_deps} LLVMDemangle)

I'm not sure how the CMake magic is supposed to work on the LLVM side.

ModuleNotFoundError: No module named 'lldb'

Hi,

When I try to debug my program from vscode with lldb(windows vscode remote to linux container) , I noticed the ModuleNotFoundError: No module named 'lldb' error in my vscode TERMINAL.

It can be simply reproduced by command line as following:

$ lldb-mi --version
Traceback (most recent call last):
  File "<string>", line 1, in <module>
ModuleNotFoundError: No module named 'lldb'
Version: GNU gdb (GDB) 7.4
(This is a MI stub on top of LLDB and not GDB)
All rights reserved.

Environment

• Debian GNU/Linux 11 (bullseye)
• llvm 14 (installed by wget https://apt.llvm.org/llvm.sh && chmod +x llvm.sh && ./llvm.sh all && apt install -y liblldb-14-dev)
• lldb-mi main(commit 2388bd7), followed https://github.com/lldb-tools/lldb-mi#building-against-system-lldb for the installation

Even though the error occurs, functions seem work correctly, not sure whether it's just a wrong prompt or a bug.

[Docs] Building on macOS

The "Building against system LLDB" instructions didn't work out-of-the-box on M1 macOS Monterey 12.4 with XCode 13.2.1.

Here's a known-good sequence of instructions. Pretty similar to the existing "Building against custom LLDB" instructions.

git clone --depth 1 https://github.com/llvm/llvm-project.git
cd llvm-project
# I think you can remove CMAKE_INSTALL_PREFIX because we do not attempt installation
cmake \
-DLLDB_USE_SYSTEM_DEBUGSERVER=ON \
-DLLDB_INCLUDE_TESTS=OFF \
-DCMAKE_BUILD_TYPE=Release \
-DLLVM_ENABLE_PROJECTS='lldb;clang' \
-DCMAKE_INSTALL_PREFIX=prefix \
-S llvm -B build -G Ninja
cmake --build build --target lldb

cd ..
git clone --depth 1 https://github.com/lldb-tools/lldb-mi.git
cd lldb-mi
cmake -DLLVM_DIR=../llvm-project/build/lib/cmake/llvm .
cmake --build .
# enjoy your new lldb-mi
./src/lldb-mi --help

-break-insert command's -f pending flag should not require an additional parameter

Copied from: https://bugs.llvm.org/show_bug.cgi?id=28698

Windows breakpoint not working

I am working on trying to get the GDB/MI Code::Blocks plugin to use the lldb-mi.exe. I am currently using the llvm-mingw-20220323-msvcrt-x86_64 release.

If i use the llgdb.exe V14.0.0 from MSYS2 (C:\msys64\clang64\bin\LLDB.exe) I can set a breakpoint and the response looks good.
If I use lldb-mi.exe v14.0.0 from https://github.com/mstorsjo/llvm-mingw/releases/tag/20220323 I cannot set a breakpoint correctly. The response is not an error, but the data looks to be bad.

Both tests are using the same exe without it being rebuilt between tests a the tests were to change the debugger plugin.

This is the request and response summary for llgdb.exe:
request: breakpoint set --file main.cpp --line 127
response: Breakpoint 1: where = clang_Printf.exe`main + 719 at main.cpp:138:20, address = 0x00000001400018af

This is the request and response summary for lldb-mi.exe:
request: 10000000000-break-insert -f D:\Andrew_Development\Z_Testing_Apps\Clang_printf\main.cpp:71
response:10000000000^done,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",pending=["D:\Andrew_Development\Z_Testing_Apps\Clang_printf\main.cpp:71"],times="0",addr="0xffffffffffffffff",func="??",file="??",fullname="??/??",line="0",original-location="D:\Andrew_Development\Z_Testing_Apps\Clang_printf\main.cpp:71"}

Attached are the full debug logs for the two test. Please note that the plugin code for the llgdd.exe does not parse the breakpoint response as it has not been changed from the GDB/MI plugin.

Am I doing something wrong or is there a bug in the lldb-mi code?
lldb-mi.txt
llgdb.txt

build failed on ubuntu20

CMake Error: The following variables are used in this project, but they are set to NOTFOUND.
Please set them or make sure they are set and tested correctly in the CMake files:
lib_lldb
linked by target "lldb-mi" in directory

[Documentation] Building against system LLDB steps

I'm trying to build lldb-mi to work against a shipped version of LLDB on macOS. Our goal is to still have lldb-mi be available but we can use debugServer that is available with XCode.

Is that possible? If so, can I do it with XCode's installed LLDB toolset or what do I need to do differently? Also I noticed that instead of using liblldb.dylib, XCode has LLDB.Framework folder but I don't know how to change lldb-mi to support that scenario.

Any help would be appreciated.

var-update command doesn't update values of expressions

The command should re-evaluate expressions but it doesn't. This functionality was broken long ago.
For this reason, expression results are constant in the "Expressions" view of Eclipse, except the expression is just a variable name.

Fails to build using CMake on Windows 10

Hello

I try to set up a debugger in KDevelop.
Unfortunately KDevelop only offers me the option LLDB (no GDB) but it requires some executable (lldb-mi.exe) that doesn't come with LLMV directly.

I have MinGW installed. With a shell opened in the unzipped folder (lldb-mi-master) I run

cmake .\CMakeLists.txt

and get the error:

CMake Error at CMakeLists.txt:15 (find_package):
Could not find a package configuration file provided by "LLVM" with any of
the following names:

LLVMConfig.cmake
llvm-config.cmake

Add the installation prefix of "LLVM" to CMAKE_PREFIX_PATH or set
"LLVM_DIR" to a directory containing one of the above files. If "LLVM"
provides a separate development package or SDK, be sure it has been
installed.

I have LLVM installed, but in its installation path ("C:\Program Files\LLVM\lib\cmake\llvm") there is only LLVMConfigExtensions.cmake

It contains only one line being:
set(LLVM_STATIC_EXTENSIONS )

After two days of searching google I am totaly stuck. I found that this apparently is an issue to other users (however in Ubuntu) as well.
--> https://bugs.launchpad.net/ubuntu/+source/llvm/+bug/1365432

Do you have any idea as to how I could finally build this project in Windows 10?

Thank you very much
Thomas

lldb-mi prints extra characters, carriage return, etc.

Using lldb-mi on MacOS Monterey 12.3, lldb 13.0.1.

Seems like using it through lldb-mi adds extra quotes and carriage returns.

(gdb)
p a
&"error: expression failed to parse:\nerror: <user expression 0>:1:1: use of undeclared identifier 'a'\na\n^\n"
^done
(gdb)
version
~"lldb version 13.0.1\n"
^done
(gdb)

Feature request: may you please move this project back to llvm project?

Debugger, such as vs code, Eclipse CDT depends on this project.

However, lldb-mi is no longer a part of llvm. Etc people have to build it on their own, which is very inconvenient.

May you please move this project back to llvm project?

Errors building with mingw-w64 toolchain

I was trying to compile with mingw-w64 and I noticed 2 errors regarding Platform.h and MIDataType.h
In Platform.h, I found a section wrapped inside an #ifdef _MSC_VER, presumably for Windows detection. The problem is that it only works for MSVC. I suggest changing _MSC_VER to _WIN32, since that will work regardless of compiler used.
In MIDataType.h, the __int64 isn't defined by default in gcc. I suggest adding #include <windows.h> into the #ifdef _WIN32 block, that way it'll get defined.

lldb-mi failed to locate lldb-server-10.0.0

When debugging applications lldb-mi report error “process launch failed: unable to locate lldb-server-10.0.0”.

Environment:
Ubuntu 20.04 LTS on WSL2
LLVM 10.0
Clang 10.0.0
LLDB 10.0.0

eclipse cdt fails, possibly because auf --interpreter

I have the version from Jan 15 2021. I was able to use this lldb-mi to debug with Eclipse with CDT on macOS 11.1.
After upgrading macOS to 11.2, debugging with Eclipse stopped working. I don't know if the upgrade was the reason.

Eclipse stalls starting the debug session. The started and running process (does not eat cpu) is
lldb-mi --interpreter mi2 --nx

Calling this manually says

(gdb)
-file-exec-and-symbols "mi2"
^error,msg="Command 'file-exec-and-symbols'. Target binary 'mi2' is invalid. error: unable to find executable for 'mi2'"
(gdb)

While lldb-mi help says
--interpreter This option is kept for backward compatibility. This executable always run in MI mode

Running manually lldb-mi --nx and then doing interactively target create my_binary works.

I assume that the 'interpreter' is not ignored as the help indicates but interpreted as executable. BTW, there is no help for --nx

Feature Request: add support for '@' parameter in the command "var-create"

Thanks for your great works!

lldb-mi doesn't support '@' as the frame parameter in "var-create" now.

It's used to create variable that doesn't bind to any frame, and is useful for watching vars in the recursive funtions.

Can it be added?

Remove unnecessary null pointer checks

An extra null pointer check is not needed in functions like the following.

• CMICmdCmdDataReadMemoryBytes
• CMICmnStreamStdin::Shutdown
• CMIUtilVariant::Destroy

Build failure on Ubuntu 20 LTS.

Repro

1. Following https://apt.llvm.org/, I installed latest llvm "sudo ./llvm.sh all" , which installed clang14
2. cmake .

Observed:

Performing C SOURCE FILE Test C_SUPPORTS_WERROR_UNGUARDED_AVAILABILITY_NEW failed with the following output:
Change Dir: /home/k/src1/lldb-mi/CMakeFiles/CMakeTmp

Run Build Command(s):/bin/make cmTC_a9240/fast && /bin/make -f CMakeFiles/cmTC_a9240.dir/build.make CMakeFiles/cmTC_a9240.dir/build
make[1]: Entering directory '/home/k/src1/lldb-mi/CMakeFiles/CMakeTmp'
Building C object CMakeFiles/cmTC_a9240.dir/src.c.o
/bin/cc -fPIC -Werror=date-time -DC_SUPPORTS_WERROR_UNGUARDED_AVAILABILITY_NEW -Werror -Werror=unguarded-availability-new -o CMakeFiles/cmTC_a9240.dir/src.c.o -c /home/k/src1/lldb-mi/CMakeFiles/CMakeTmp/src.c
cc1: error: '-Werror=unguarded-availability-new': no option -Wunguarded-availability-new
make[1]: *** [CMakeFiles/cmTC_a9240.dir/build.make:66: CMakeFiles/cmTC_a9240.dir/src.c.o] Error 1
make[1]: Leaving directory '/home/k/src1/lldb-mi/CMakeFiles/CMakeTmp'
make: *** [Makefile:121: cmTC_a9240/fast] Error 2

Source file was:
int main(void) { return 0; }
Performing C++ SOURCE FILE Test CXX_SUPPORTS_WERROR_UNGUARDED_AVAILABILITY_NEW failed with the following output:
Change Dir: /home/k/src1/lldb-mi/CMakeFiles/CMakeTmp

Run Build Command(s):/bin/make cmTC_1db1f/fast && /bin/make -f CMakeFiles/cmTC_1db1f.dir/build.make CMakeFiles/cmTC_1db1f.dir/build
make[1]: Entering directory '/home/k/src1/lldb-mi/CMakeFiles/CMakeTmp'
Building CXX object CMakeFiles/cmTC_1db1f.dir/src.cxx.o
/bin/c++ -fPIC -fvisibility-inlines-hidden -Werror=date-time -DCXX_SUPPORTS_WERROR_UNGUARDED_AVAILABILITY_NEW -Werror -Werror=unguarded-availability-new -o CMakeFiles/cmTC_1db1f.dir/src.cxx.o -c /home/k/src1/lldb-mi/CMakeFiles/CMakeTmp/src.cxx
cc1plus: error: '-Werror=unguarded-availability-new': no option -Wunguarded-availability-new
make[1]: *** [CMakeFiles/cmTC_1db1f.dir/build.make:66: CMakeFiles/cmTC_1db1f.dir/src.cxx.o] Error 1
make[1]: Leaving directory '/home/k/src1/lldb-mi/CMakeFiles/CMakeTmp'
make: *** [Makefile:121: cmTC_1db1f/fast] Error 2

Source file was:
int main() { return 0; }
Determining if the os_signpost_interval_begin exist failed with the following output:
Change Dir: /home/k/src1/lldb-mi/CMakeFiles/CMakeTmp

Run Build Command(s):/bin/make cmTC_e4556/fast && /bin/make -f CMakeFiles/cmTC_e4556.dir/build.make CMakeFiles/cmTC_e4556.dir/build
make[1]: Entering directory '/home/k/src1/lldb-mi/CMakeFiles/CMakeTmp'
Building C object CMakeFiles/cmTC_e4556.dir/CheckSymbolExists.c.o
/bin/cc -fPIC -Werror=date-time -w -ffunction-sections -fdata-sections -o CMakeFiles/cmTC_e4556.dir/CheckSymbolExists.c.o -c /home/k/src1/lldb-mi/CMakeFiles/CMakeTmp/CheckSymbolExists.c
/home/k/src1/lldb-mi/CMakeFiles/CMakeTmp/CheckSymbolExists.c:2:10: fatal error: os/signpost.h: No such file or directory
2 | #include <os/signpost.h>
| ^~~~~~~~~~~~~~~
compilation terminated.
make[1]: *** [CMakeFiles/cmTC_e4556.dir/build.make:66: CMakeFiles/cmTC_e4556.dir/CheckSymbolExists.c.o] Error 1
make[1]: Leaving directory '/home/k/src1/lldb-mi/CMakeFiles/CMakeTmp'
make: *** [Makefile:121: cmTC_e4556/fast] Error 2

File /home/k/src1/lldb-mi/CMakeFiles/CMakeTmp/CheckSymbolExists.c:
/* */
#include <os/signpost.h>

int main(int argc, char** argv)
{
(void)argv;
#ifndef os_signpost_interval_begin
return ((int*)(&os_signpost_interval_begin))[argc];
#else
(void)argc;
return 0;
#endif
}

Slow stepping through code with many threads

Hello, iam using plugin for vscode build on top of lldb-mi. It seems like lldb-mi takes really long time to step through code with many threads running. I did capture hot path trace to help you identify problem it is available along with much more details in bugreport i made for plugin itself as i originaly thought it was caused by them:

microsoft/vscode-cpptools#7250

How to avoid -lLLVM error

I have a clang compiler installed on my system, but am trying to use the clang that I've built myself, configuring lldb-mi with:

export CC=/opt/lzlabs/gcc-9.2.0/bin/gcc
export CXX=/opt/lzlabs/gcc-9.2.0/bin/g++
#export CXX="/opt/lzlabs/gcc-9.2.0/bin/g++ -std=c++14"

export LD_LIBRARY_PATH=/opt/lzlabs/gcc-9.2.0/lib64:/opt/lzlabs/lldb/lib64

export PATH=/opt/lzlabs/gcc-9.2.0/bin:/home/pjoot/gdb/bin:/opt/lzlabs/lldb/bin:$PATH

cmake
-DCMAKE_PREFIX_PATH=/opt/lzlabs/lldb
-DBUILD_SHARED_LIBS=true
-DCMAKE_BUILD_TYPE=Release
-DCMAKE_SHARED_LINKER_FLAGS='-B/home/pjoot/gdb/bin'
-DCMAKE_EXE_LINKER_FLAGS='-B/home/pjoot/gdb/bin'
-DLLVM_LIBDIR_SUFFIX=64
-DCMAKE_INSTALL_RPATH=/opt/lzlabs/gcc-9.2.0/lib64:/opt/lzlabs/lldb/lib64
-DCMAKE_BUILD_WITH_INSTALL_RPATH=TRUE
-GNinja ../lldb-mi

I end up with an error when lldb-mi is linked as my build.ninja tries to use -lLLVM (which curiously doesn't seem to exist in either the llvm that is part of the old clang-3.8 that is installed on my system, nor in my just built llvm+lldb (trunk))

I was able to work around that by changing the build.ninja reference to -lLLVM into llvm-config --libs (that's backquotes mangled by markup into highlighted text)

Is there a proper way to do this, without hacking the generated build.ninja?

Can lldb-mi be placed into the llvm/tools directory and built with the rest ?

That way "lldb-mi" would still be an optional download. It would work as before in terms of building it. Placing code into tools seems to be the llvm preferred way to build optional tools anyway, so the installation/build instructions could be even simpler. Just wondering...

error build in alt linux

Hi,
Missing which package might cause the following error?
output :

-- Found LLVM 13.0.1
-- Using LLVMConfig.cmake in: /usr/lib64/cmake/llvm
CMake Error at CMakeLists.txt:21 (include):
include could not find requested file:

HandleLLVMStdlib

CMake Error at CMakeLists.txt:22 (include):
include could not find requested file:

HandleLLVMOptions

-- Configuring incomplete, errors occurred!
See also "/home/nilopurple/lldb-mi/CMakeFiles/CMakeOutput.log".

Build cannot find LLVMConfig.cmake OR Error Behind Keyboard

Hi,

I'm using llvm-mingw to cross build itself on FreeBSD for Windows 10. My filesystem is laid out as so:

russellh@jailbird:/storage> tree -L 2
.
|-- build
|   |-- 2004
|   |-- llvm-mingw-host
|   `-- winlua-2004b.zip
|-- git
|   |-- libressl-portable
|   |-- lldb-mi
|   |-- llvm-mingw
|   |-- lua-5.3.4-op_halt
|   |-- luafilesystem
|   |-- luarocks
|   |-- sol2
|   `-- xmake
|-- physionet
|   |-- wfdb-10.6.2
|   `-- wfdb.tar.gz
|-- scripts
|   |-- README.md
|   |-- cmake
|   |-- license.txt
|   `-- winlua-build.sh
|-- sources
|   |-- netpgp-20140220
|   |-- orig_dir
|   |-- patches
|   |-- tars
|   |-- wlc-wrapper
|   |-- work
|   `-- zlib-1.2.11
`-- test.txt

llvm-mi is in /storage/git/ and llvm is a under /storage/git/llvm-mingw/llvm-project.

I would like to build lldb-mi for Windows. My LLVM Windows "installation" is in storage/build/<arch>/WLC.

Build shell script:

        cd /storage/git/lldb-mi
        mkdir build_$MINGW_PLATFORM
        cd build_$MINGW_PLATFORM

        echo $INSTALL_ROOT/$WIN_PLATFORM/WLC/
		
        cmake -GNinja -DBUILD_SHARED_LIBS=ON \
                -DCMAKE_TOOLCHAIN_FILE=$CMAKE_X_DIR/$MINGW_PLATFORM-w64-mingw32.cmake \
                -DCMAKE_PREFIX_PATH="$INSTALL_ROOT/$WIN_PLATFORM/WLC/" \
                -DCMAKE_INSTALL_PREFIX="$INSTALL_ROOT/$WIN_PLATFORM/WLC/lldb-mi" \
                ..
        ninja && ninja install

Output

mkdir: build_i686: File exists
/storage/build/2004/x86/WLC/
CMake Error at CMakeLists.txt:10 (find_package):
  Could not find a package configuration file provided by "LLVM" with any of
  the following names:

    LLVMConfig.cmake
    llvm-config.cmake

  Add the installation prefix of "LLVM" to CMAKE_PREFIX_PATH or set
  "LLVM_DIR" to a directory containing one of the above files.  If "LLVM"
  provides a separate development package or SDK, be sure it has been
  installed.


-- Configuring incomplete, errors occurred!
See also "/storage/git/lldb-mi/build_i686/CMakeFiles/CMakeOutput.log".
ninja: error: loading 'build.ninja': No such file or directory

A search of my LLVM build directory finds:

russellh@jailbird:/storage/git/llvm-mingw> find . -name "LLVMConfig.cmake"
./llvm-project/llvm/build-x86_64-w64-mingw32/cmake/modules/CMakeFiles/LLVMConfig.cmake
./llvm-project/llvm/build-x86_64-w64-mingw32/lib/cmake/llvm/LLVMConfig.cmake
./llvm-project/llvm/build/lib/cmake/llvm/LLVMConfig.cmake
./llvm-project/llvm/build/cmake/modules/CMakeFiles/LLVMConfig.cmake
./llvm-project/llvm/build-i686-w64-mingw32/cmake/modules/CMakeFiles/LLVMConfig.cmake
./llvm-project/llvm/build-i686-w64-mingw32/lib/cmake/llvm/LLVMConfig.cmake

So, finally my questions:

• Should I copy the LLVMConfig.cmake from my build directory to my installation directory? OR should I be pointing to my LLVM build directory?
• If I am to LLVMConfig.cmake, which file (modules, lib or arch specific?) should I move, and where should they be moved to?
• I wonder if the LLVM ninja install script should have copied LLVMConfig.cmake file? (That would denote there is possibly an error)

Any advice would be grand.
Thanks!
Russell

Build issue on Linux (Ubuntu 20)

# cmake .
-- Found LLVM 16.0.4
-- Using LLVMConfig.cmake in: /usr/lib/llvm-16/cmake
-- Building with -fPIC
CMake Error: The following variables are used in this project, but they are set to NOTFOUND.
Please set them or make sure they are set and tested correctly in the CMake files:
lib_lldb
    linked by target "lldb-mi" in directory /root/lldb-mi/src

-- Configuring incomplete, errors occurred!
See also "/root/lldb-mi/CMakeFiles/CMakeOutput.log".
See also "/root/lldb-mi/CMakeFiles/CMakeError.log".

Note, for my system I have Clang 15 installed along side Clang 16. The former is linked through commands like clang, clang++, cc and c++. So I define these environment variables:

export CMAKE_C_COMPILER_ID='Clang'
export CMAKE_C_COMPILER='/usr/bin/clang-16'
export CMAKE_CXX_COMPILER_ID='Clang'
export CMAKE_CXX_COMPILER='/usr/bin/clang++-16'
export LLDB_DEBUGSERVER_PATH='/usr/lib/llvm-16/lib/liblldb'

`breakpoint-hit` event doesn't respect `target.source-map` for remote target

The "fullname" field in the breakpoint-hit stopped event doesn't contain the mapped path. I've captured both the lldb-mi and gdb commands and traces for comparison. Based on the mapping the /usr/src/hello_world.c source path should be mapped to /home/troy/git/hello_world_c/hello_world.c, but is instead being reported without the mapping (i.e., /usr/src/hello_world.c).

Additionally, bkptno doesn't match the actual breakpoint number either.

lldb-mi

commands

lldb-server gdbserver 0:2345 hello_world &
lldb-mi
settings append target.source-map /usr/src /home/troy/git/hello_world_c
settings show target.source-map
-target-select remote 0:2345
-break-insert -t -f main
-exec-continue

lldb-mi trace

> lldb-server gdbserver 0:2345 hello_world &
[1] 224602
Launched 'hello_world' as process 224603...
lldb-server-local_build
> lldb-mi
Traceback (most recent call last):
  File "<string>", line 1, in <module>
ModuleNotFoundError: No module named 'lldb.embedded_interpreter'
(gdb)
settings append target.source-map /usr/src /home/troy/git/hello_world_c
^done
(gdb)
settings show target.source-map
~"target.source-map (path-map) =\n[0] \"/usr/src\" -> \"/home/troy/git/hello_world_c\"\n\n"
^done
(gdb)
-target-select remote 0:2345
Connection established.
^connected
=thread-group-started,id="i1",pid="224603"
(gdb)
=thread-created,id="1",group-id="i1"
=thread-selected,id="1"
(gdb)
*stopped,reason="signal-received",signal-name="SIGSTOP",signal-meaning="Stop",frame={level="0",addr="0x00007ffff7fe32b0",func="_start",file="??",fullname="??",line="-1"},thread-id="1",stopped-threads="all"
(gdb)
-break-insert -t -f main
^done,bkpt={number="1",type="breakpoint",disp="del",enabled="y",pending=["main"],times="0",addr="0x000055555555514f",func="main",file="hello_world.c",fullname="/usr/src/hello_world.c",line="8",original-location="main"}
(gdb)
-exec-continue
^running
(gdb)
*running,thread-id="all"
(gdb)
(gdb)
*stopped,reason="breakpoint-hit",disp="del",bkptno="0",frame={level="0",addr="0x000055555555514f",func="main",args=[],file="hello_world.c",fullname="/usr/src/hello_world.c",line="8"},thread-id="1",stopped-threads="all"
(gdb)

gdb

commands

gdbserver 0:2345 hello_world &
gdb -q --interpreter=mi2
-gdb-set substitute-path /usr/src /home/troy/git/hello_world_c
-target-select remote 0:2345
-break-insert -t -f main
-exec-continue

gdb trace

> gdbserver 0:2345 hello_world
Process /home/troy/git/hello_world_exe/hello_world created; pid = 232163
Listening on port 2345
Remote debugging from host 127.0.0.1, port 52854
> gdb -q --interpreter=mi2
=thread-group-added,id="i1"
(gdb) 
-gdb-set substitute-path /usr/src /home/troy/git/hello_world_c
^done
(gdb) 
-target-select remote 0:2345
=tsv-created,name="trace_timestamp",initial="0"
=thread-group-started,id="i1",pid="232163"
~"Reading /home/troy/git/hello_world_exe/hello_world from remote target...\n"
&"warning: File transfers from remote targets can be slow. Use \"set sysroot\" to access files locally instead.\n"
~"Reading /home/troy/git/hello_world_exe/hello_world from remote target...\n"
~"Reading symbols from target:/home/troy/git/hello_world_exe/hello_world...\n"
=thread-created,id="1",group-id="i1"
~"Reading /lib64/ld-linux-x86-64.so.2 from remote target...\n"
~"Reading /lib64/ld-linux-x86-64.so.2 from remote target...\n"
=library-loaded,id="/lib64/ld-linux-x86-64.so.2",target-name="/lib64/ld-linux-x86-64.so.2",host-name="target:/lib64/ld-linux-x86-64.so.2",symbols-loaded="0",thread-group="i1",ranges=[{from="0x00007ffff7fc5090",to="0x00007ffff7fee335"}]
~"Reading /usr/lib/debug/.build-id/21/a2739157f98ff49d8920f47723a6a3ddb1f4d1.debug from remote target...\n"
~"0x00007ffff7fe32b0 in _start () from target:/lib64/ld-linux-x86-64.so.2\n"
*stopped,frame={addr="0x00007ffff7fe32b0",func="_start",args=[],from="target:/lib64/ld-linux-x86-64.so.2",arch="i386:x86-64"},thread-id="1",stopped-threads="all",core="1"
^connected
(gdb) 
-break-insert -t -f main
^done,bkpt={number="1",type="breakpoint",disp="del",enabled="y",addr="0x000055555555514f",func="main",file="hello_world.c",fullname="/home/troy/git/hello_world_c/hello_world.c",line="8",thread-groups=["i1"],times="0",original-location="main"}
(gdb) 
-exec-continue
^running
*running,thread-id="all"
(gdb) 
~"Reading /lib/x86_64-linux-gnu/libc.so.6 from remote target...\n"
=library-loaded,id="/lib/x86_64-linux-gnu/libc.so.6",target-name="/lib/x86_64-linux-gnu/libc.so.6",host-name="target:/lib/x86_64-linux-gnu/libc.so.6",symbols-loaded="0",thread-group="i1",ranges=[{from="0x00007ffff7da1700",to="0x00007ffff7f33abd"}]
=breakpoint-modified,bkpt={number="1",type="breakpoint",disp="del",enabled="y",addr="0x000055555555514f",func="main",file="hello_world.c",fullname="/home/troy/git/hello_world_c/hello_world.c",line="8",thread-groups=["i1"],times="1",original-location="main"}
~"\n"
~"Temporary breakpoint 1, main () at hello_world.c:8\n"
~"8\t  int i = 77;\n"
*stopped,reason="breakpoint-hit",disp="del",bkptno="1",frame={addr="0x000055555555514f",func="main",args=[],file="hello_world.c",fullname="/home/troy/git/hello_world_c/hello_world.c",line="8",arch="i386:x86-64"},thread-id="1",stopped-threads="all",core="2"
=breakpoint-deleted,id="1"
(gdb) 

Binaries fo Windows

Can we please get Binaries, it is not an easy task to build everything from source.

Wrong source file patch on windows

when use lldb-mi with vscode , vscode show Unable to open 'test.cpp': Unable to read file '\test.cpp' (Error: Unable to resolve non-existing file '\test.cpp').
then I test gdb and lldb-mi difference
gdb response

*stopped,reason="breakpoint-hit",disp="keep",bkptno="2",frame={addr="0x00007ff74b141486",func="main",args=[],file="D:\\/Work\\lldbtest\\test.cpp",fullname="D:\\Work\\lldbtest\\test.cpp",line="4",arch="i386:x86-64"},thread-id="1",stopped-threads="all"

lldb-mi response

*stopped,reason="breakpoint-hit",disp="del",bkptno="1",frame={level="0",addr="0x00007ff74b141486",func="main",args=[],file="test.cpp",fullname="/test.cpp",line="4"},thread-id="1",stopped-threads="all"

the fullname is not full.

Breakpoints under Windows, wrong file path returned by lldb-mi

Hello,

When reaching a breakpoint under Windows (I use Visual Studio Code with C/C++ extension), file path returned by lldb-mi is wrong.

For example, if my source file is D:/dir1/sudir1/file.cpp, file path returned by lldb-mi is D:dir1sudir1file.cpp.

Vincent

Incorrect fullname under windows when lldb-mi startup path and source path are not in the same partition

lldb-mi.exe under E:\llvm14\bin\, and source file under K:\Work\cmaketest\hello.c, mingw crt source under E:\Source\git\mingw-w64\mingw-w64-crt, the -stack-list-frames result is

stack: [frame={level=0,addr=0x00007ff6449f148d,func=main,file=hello.c,fullname=/K:/Work/cmaketest/hello.c,line=5},frame={level=1,addr=0x00007ff6449f13d7,func=__tmainCRTStartup,file=crtexe.c,fullname=E:/Source/git/mingw-w64/mingw-w64-crt/crt/crtexe.c,line=321},frame={level=2,addr=0x00007ff6449f1436,func=mainCRTStartup,file=crtexe.c,fullname=E:/Source/git/mingw-w64/mingw-w64-crt/crt/crtexe.c,line=202},frame={level=3,addr=0x00007fff162d244d,func=BaseThreadInitThunk,file=??,fullname=??,line=-1},frame={level=4,addr=0x00007fff16fadf88,func=RtlUserThreadStart,file=??,fullname=??,line=-1}]

when I start lldb-mi.exe from C:\, the -stack-list-frames changed to

stack=[frame={level="0",addr="0x00007ff6449f1486",func="main",file="hello.c",fullname="/K:/Work/cmaketest/hello.c",line="4"},frame={level="1",addr="0x00007ff6449f13d7",func="__tmainCRTStartup",file="crtexe.c",fullname="/E:/Source/git/mingw-w64/mingw-w64-crt/crt/crtexe.c",line="321"},frame={level="2",addr="0x00007ff6449f1436",func="mainCRTStartup",file="crtexe.c",fullname="/E:/Source/git/mingw-w64/mingw-w64-crt/crt/crtexe.c",line="202"},frame={level="3",addr="0x00007fff162d244d",func="BaseThreadInitThunk",file="??",fullname="??",line="-1"},frame={level="4",addr="0x00007fff16fadf88",func="RtlUserThreadStart",file="??",fullname="??",line="-1"}]

-stack-list-frames returned by gdb

stack: [frame={level=0,addr=0x00007ff6449f148d,func=main,file=K:/Work/cmaketest/hello.c,fullname=K:\Work\cmaketest\hello.c,line=5,arch=i386:x86-64}]

CMICmnLLDBDebugSessionInfo::ResolvePath method will check path is accessible.
When the source file E:\Source\git\mingw-w64\mingw-w64-crt\crt\crtexe.c and the lldb-mi startup path are in the same partition, the last detected path is /Source/git/mingw-w64/ mingw-w64-crt/crt/crtexe.c,

lldb-mi/src/MICmnLLDBDebugSessionInfo.cpp

Line 339 in 2388bd7

if (bYesAccessible) {

bYesAccessible is true

lldb-mi/src/MICmnLLDBDebugSessionInfo.cpp

Lines 340 to 344 in 2388bd7

	#ifdef _WIN32
	if (nFoldersBack == (vecPathFolders.size() - 1)) {
	// First folder is probably a Windows drive letter ==> must be returned
	vwrResolvedPath = vecPathFolders[0] + strTestPath;
	} else {

then will put drive letter before path and return it.

But if the source file K:\Work\cmaketest\hello.c and lldb-mi startup path are not in the same partition, /Work/cmaketest/hello.c is not accessible, then will test next path/K:/Work/cmaketest/hello.c and return it.

CMICmnLLDBDebugSessionInfo::ResolvePath has another problem, it also returns the wrong path if the parent directory contains a file with the same name as the source file. For example, my source file path is K:\Work\cmaketest\hello.c. If there is a file in K:\hello.c at this time, according to the current algorithm, /hello.c can be accessed, will directly return K:/hello.c.

Doesn't compile with Clang (macOS), missing -std flag?

Using macOS 10.14.6, Xcode 11.1 (Apple clang version 11.0.0 clang-1100.0.33.8)

If I try to compile lldb-mi with the given instructions, I get errors/warnings such as:

error: a space is required between consecutive right angle brackets (use '> >')
error: exception specification of overriding function is more lax than base version
warning: rvalue references are a C++11 extension [-Wc++11-extensions]

It looks like lldb-mi doesn't specify the "-std" flag which should be c++14 for LLVM-based tools. Combined with the fact that Clang on macOS still seems to compile in c++98 by default, this would explain the errors. If I add it to the CMakeLists.txt by hand, then it works correctly:

append("-std=c++14" CMAKE_CXX_FLAGS)

I checked if there was a way not to duplicate the argument and try to inherit whichever LLVM was using. The best way I found was do to this:

include(HandleLLVMOptions)

I don't know if that's the proper way to go, as I do not see it in the LLVM documentation. I also get some CMake warnings "Policy CMP0077 is not set: option() honors normal variables.". I'm not very knowledgeable in CMake so I'm not sure if that's OK.

lldb-mi does not implement gdb cwd interface causing vscode to debug from the wrong location

I am running lldb via vscode's cppdbg. Although I am specifying the current working directory in my vscode settings, to debug from, when I use lldb, my application is debugged running from the path where the executable resides, instead of the directory I've specified.

I have raised this issue with vscode-cpptools. It is believed that this is potentially an issue/improvement with llvm mi, as per microsoft/vscode-cpptools#8052

when debugging using lldb and I run '-exec "show cwd"' in vscode's debug console, I get "error: 'show' is not a valid command. ", which indicates that lldb does not implement this feature.

Could you point me in the right direction so I could possibly implement this gdb MI interface to change cwd when debugging?

Many thanks.