LLDB debugger support
#3645
Replies: 14 comments 26 replies
-
|
Honestly, I would wait until the non-beta 10.1 gets released. The instructions are in Ghidra/Debug/Debugger-agent-lldb/data (I think) but they are a colossal pain. We’re working hard to simplify them. |
Beta Was this translation helpful? Give feedback.
2 replies
-
Literally spent a few hours last night trying to figure out how to rebind the lldb python bindings to a non-ancient version of python without having to completely recompile it. Even though LLVM is the best it still sucks in this area although it is usually only a windows problem. If the |
Beta Was this translation helpful? Give feedback.
-
|
There's a decent bit of code to provide complete Java language and "scripting" bindings. We have submitted it upstream, but there's a bit of a process. |
Beta Was this translation helpful? Give feedback.
-
|
Now that 10.1 is out and the old instructions are gone what are the new instructions? |
Beta Was this translation helpful? Give feedback.
4 replies
-
|
Debugger-swig-lldb |
Beta Was this translation helpful? Give feedback.
-
I like these instructions. Will see how it fairs tomorrow. |
Beta Was this translation helpful? Give feedback.
-
|
Good luck - yell if things go awry. |
Beta Was this translation helpful? Give feedback.
-
The android app wouldn't let me edit and you beat me to it. In my half asleep ness I assumed it was just type that command and let it do its thing. I'll leave the comment there though for others amusement. |
Beta Was this translation helpful? Give feedback.
-
|
They are located in the installation: ghidra_10.1_PUBLIC/Ghidra/Debug/Debugger-swig-lldb/InstructionsForBuildingLLDBInterface.txt, or in the repo: https://github.com/NationalSecurityAgency/ghidra/blob/master/Ghidra/Debug/Debugger-swig-lldb/InstructionsForBuildingLLDBInterface.txt |
Beta Was this translation helpful? Give feedback.
12 replies
-
|
There was a point in time where gradle 7+ wasn't supported yet and I just hadn't upgraded yet. I did get a build failure with the "vanilla" llvm for windows install but I expected this since they don't give you the lldb headers. I will try again on my workstation in the office tomorrow after updating gradle. I have the whole llvm toolchain built with full LTO which was compiled by llvm built with full LTO (don't ask why). |
Beta Was this translation helpful? Give feedback.
-
|
I tried with gradle 7.3 and had to do quite a bit of changing of toolchain args to get it to build with clang for windows. The only thing I can't seem to get around is: "Could not find Static library archiver 'ar' in system path." Which is because it doesn't exist of course. |
Beta Was this translation helpful? Give feedback.
-
|
OK, so, for starters, you could download LLVM-13.0.0-win64.exe from github.com/llvm/llvm-project/releases/tag/llvmorg-13.0.0 and skip the whole building thing. You only need the liblldb.lib and header files to build liblldb-java. The former is in that package; the latter in the GitHub repo. That said, assuming you're in it for the challenge, here's what I used for Windows.... I used the CMake gui with the following checked: CLANG_BUILD_TOOLS, CLANG_ENABLE_ARCMT, CLANG_ENABLE_STATIC_ANALYZER, CLANG_INCLUDE_DOCS, CLANG_INCLUDE_TESTS, CLANG_INSTALL_SCANBUILD, CLANG_INSTALL_SCANVIEW, CLANG_PLUGIN_SUPPORT, CLANG_TOOLING_BUILD_AST_INSPECTION, CLANG_TOOL_HANDLE_CXX_BUILD, CLANG_TOOL_HANDLE_LLVM_BUILD, CMAKE_AR=C:/Program Files (x86)/Microsoft Visual Stdio/2019/Community/VC/Tools/MSVC/14.28.29910/bin/Hostx64/lib.exe, CMAKE_BUILD_TYPE=Release, CMAKE_CXX_STANDARD=14, CMAKE_INSTALL_PREFIX=C:/Program Files (x86)/LLVM, CUDA_HOST_COMPILER=as above/cl.exe, ENABLE_X86_RELAX_LOCATIONS, HAVE_STD_REGEX, LLDB_BUILD_INTEL_MPX, LLDB_EMBED_PYTHON_HOME, LLDB_INCLUDE_TESTS, LLDB_PYTHON_HOME=C:/Program Files/Python310, LLDB_TEST_ARCH=x86_64, LLDB_TOOL_LLDB_INSTR_BUILD, LLDB_TOOL_LLDB_SERVER_BUILD, LLDB_TOOL_LLDB_VSCODE_BUILD, LLVM_APPEND_VC_REV, LLVM_BUILD_LLVM_C_DYLIB, LLVM_BUILD_RUNTIME, LLVM_BUILD_RUNTIMES, LLVM_BUILD_TOOLS, LLVM_BUILD_UTILS, LLVM_DEFAULT_TARGET_TRIPLE=x86_64-pc-windows-msvc, LLVM_ENABLE_ASSERTIONS, LLVM_ENABLE_BACKTRACES, LLVM_ENABLE_BINDINGS, LLVM_ENABLE_DIA_SDK, LLVM_ENABLE_LIBEDIT, LLVM_ENABLE_LIBPFM, LLVM_ENABLE_LIBXML2=ON, LLVM_ENABLE_LOCAL_SUBMODULE_VISIBILITY, LLVM_ENABLE_LTO=OFF, LLVM_ENABLE_NEW_PASS_MANAGER, LLVM_ENABLE_OCAMLDOC, LLVM_ENABLE_PDEANTIC, LLVM_ENABLE_PIC, LLVM_ENABLE_PROJECTS=clang;libxcxx;lldb, LLVM_ENABLE_TERMINFO, LLVM_ENABLE_THREADS, LLVM_ENABLE_UNWIND_TABLES, LLVM_ENABLE_WARNINGS, LLVM_ENABLE_ZLIB=ON, LLVM_EXTERNAL_xxx_SOURCE_DIR=all pointing to LLVM github clone, LLVM_HOST_TRIPLE=x86_64-pc-windows-msvc, LLVM_INCLUDE_BENCHMARKS, LLVM_INCLUDE_DOCS, LLVM_INCLUDE_EXAMPLES, LLVM_INCLUDE_GO_TESTS, LLVM_INCLUDE_RUNTIMES, LLVM_INCLUDE_TESTS, LLVM_INCLUDE_TOOLS, LLVM_INCLUDE_UTILS, LLVM_LIT_ARGS=-sv, LLVM_OPTIMIZE_SANITIZED_BUILDS, LLVM_TARGETS_TO_BUILD=all, LLVM_TOOL_CLANG_BUILD, LLVM_TOOL_LIBCXX_BUILD, LLVM_TOOL_LLDB_BUILD, LLVM_USE_CRT_DEBUG=MDd, LLVM_USE_CRT_RELEASE-MD, LLVM_PRINTER+SHOW_HOST_TARGET..., MSVC_DIA_SDK_DIR=C:/Program Files (x86)/Microsoft Visual Stdio/2019/Community/DIA_SDK, NINJA_VERSION=1.10.2 I HIGHLY recommend going the Ninja route vs, Visual Studio or other options. Gradle version was 7.0.2 (although irrelevant for the LLVM build). Let me know when you get to the Ghidra piece. Best, D |
Beta Was this translation helpful? Give feedback.
-
|
Ok, so if only I could read and follow instructions I would have been in much better shape. I managed to build it on my laptop which has a proper visual studio install (the gradle scripts still hate clang for windows and visual studio build tools). Only one correction I have for the instructions. On windows I had to set You might also want to modify the flow of the instructions a bit. If you currently have llvm-13.0 installed then the way the instructions flow you would skip over step 2 and thus not have the lldb headers. It is something I should have noticed when "following" the instructions to set |
Beta Was this translation helpful? Give feedback.
-
|
Will definitely take a stab at clarifying the directions. (The first two attempts were actually worse.) |
Beta Was this translation helpful? Give feedback.
-
|
I was able to get things sort of working with those instructions. I can step using the interpreter window, but there is no mapping showing in the "Static Mappings" window. Should I expect a static mapping to show automatically? |
Beta Was this translation helpful? Give feedback.
7 replies
-
|
AFAICT, it's using |
Beta Was this translation helpful? Give feedback.
-
|
That's correct re GetNumModules and GetModuleAtIndex - and, yes, should be more or less identical to "image list" issued in the Interpreter. If "image list" works and Modules is still empty, the '"Refresh" on the Modules node in the Objects view' trck should work. If not, not sure what's going on. :( |
Beta Was this translation helpful? Give feedback.
-
|
The modules do show up in the session of the "Objects" window but not in the "Modules" window. Refreshing the node doesn't help. The log suggests something is going wrong: |
Beta Was this translation helpful? Give feedback.
-
|
I tried 10.1.1 and the NPE seem to be gone, but the "Modules" window is still empty. I also noticed that a thread seems to be using 100% CPU calling |
Beta Was this translation helpful? Give feedback.
-
If you are on windows try just running lldb and see what happens. I don't know if it is related or not but the lldb shipped with the clang for windows installer is hardcoded to load python36.dll and won't start without it. |
Beta Was this translation helpful? Give feedback.
-
|
OK, that’s super helpful - will dive into a bit deeper tomorrow. The “range” errors probably don’t matter - some code gets hit twice, once a little too early - but the NPEs in getModuleLoaded/Unloaded are definitely an issue. Not sure why I haven’t seen this before. May try to set up 10.15 in a VM and see if it’s related. Thanks and apologies! |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
d-millar, Maybe you can help with simple instructions to install lldb for Ghidra 10.1.5. I have m1 MBP, Xcode 14, command line tools, Hopper, I have installed swig, cmake, gradle, - none of which I have ever used before. I can compile and run trivial C programs from the command line, and am reasonably familiar w ever, I would like an operational tool in Ghidra. I am a very senior citizen, but I can generally follow instructions, if they are clear. So far, I have discovered that the installation instructions for lldb, included with Ghidra don’t seem to work for me. I have also followed the procedure put together by someone with M1, but from recollection the final cmake step failed with a cryptic (to me) error about missing source files. Are there any updated documents available? Assume my IQ has dropped to double digits. Thanks in advance. |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
@Durakill Happy to help on this, although I should warn you you're diving into the deep end of the pool - getting lldb set up and intergrated with Ghidra on an M1 processor is arguably the most difficult thing you can do with the debugger. Why? Because in addition to two fairly complicated build processes (lldb and Ghidra) and the SWIG/JNI interface which is tricky and fragile, the M1 mixed environment is a bit of a mine field. Specifically, if the components are not either all x86_64 or all arm/aarch, nothing will work - and the error messages will not be helpful. To get started, am assuming you've read InstructionsForBuildingLLDBInterface.txt in ghidra/Ghidra/Debug/Debugger-swig-lldb. If so, are you using an installed version of lldb, say from XCode, or are you trying to build lldb from scratch? Can you send me the version numbers for lldb, swig, gradle, ninja, java, Ghidra, etc.? Also, can you verify whether each is x86_64 or ARM (using "file" or equiv)? FYI, if we can get by without doing step 2a, i.e. building lldb from scratch, life will be easier. |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
@Durakill OK, just walked through my own instructions noting pitfalls and am going to try to give the most explicit instructions I can. Note: the following instruction assume you do NOT have to build lldb from scratch, i.e. they assume you have version 14. If you don't, let me know. Here goes (assuming a user name "dk" with a sub-directory in his home dir called "src": |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
d-millar, Thanks for you amazingly prompt response, and your detailed instructions. By the way, my name is Michael - the Durakill is part of old email address. Either will do. I will start, but FYI, here is what I have - Swig 4.0.2 Mach-O 64-bit executable arm64 I am assuming that the file result for lldb, for example, is what you refer to as Mach-O universal, but I will assume it doesn’t matter unless you advise otherwise! OK, here goes! Up, up, and awaaaay! |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
That all looks pretty good, and, yes, regarding “Mach-O universal”. I believe Ghidra will run under JDK 18 versions, although I believe there are issues building it from source, so probably not an issue for this. (JDK 17 is the latest stable release, I believe - 18 is exploratory if I remember correctly.) Fingers crossed - looking forward to see ping your results! |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
d-millar, Close. I made a couple of changes to correct minor errors. Eg. - file /System/Volumes/opt/homebrew/Cellar/llvm/14.0.6_1/lib/liblldb.dylb My hombrew is in MacintoshHD, and my liblldb is at /opt/homebrew/Cellar/llvm/15.0.2/lib/liblldb.dylib File command file /opt/homebrew/Cellar/llvm/15.0.2/lib/liblldb.dylib I changed your VMARGS=-Djava.library.path=/System/Volumes/Data/opt/homebrew/Cellar/llvm/14.0.6_1/lib:/Users/dk/src/ghidra_10.1.5_PUBLIC/Ghidra/Debug/Debugger-swig-lldb/build/os/mac_arm_64/lib To VMARGS=-Djava.library.path=/opt/homebrew/Cellar/llvm/15.0.2/lib:/Users/michaelflynn/src/ghidra_10.1.5_PUBLIC/Ghidra/Debug/Debugger-swig-lldb/build/os/mac_arm_64/lib Try to connect using IN-VM local lldb debugger fails, with Debug Console giving - liblldb-java not found - add relevant java.library.path to support/launch.properties I have feeling I have had this following error before, so I must have got close previously (somehow or t’other) - 'int SWIG.lldbJNI.SBProcess_eBroadcastBitStateChanged_get()' Build Date: 2022-Jul-26 1543 EDT Very close, but no cigar. I may have made a mistake with launch.properties, but it looks OK to me. Maybe there is some small thing (or large thing) I have stuffed up. I changed a couple of your llvm paths because I had 15.02. Anyway, getting there - just one small error somewhere. Thanks. |
Beta Was this translation helpful? Give feedback.
1 reply
-
|
Well, one immediate decision you're going to have to make is whether you're going to use 14 or 15. Your "file" on lldb returned 14, but you set all your build variables to point to 15. What did you use for "gradle generateSwig" (i.e. LLVM_HOME and the "git checkout") and for "gradle build" (i.e. LLVM_BUILD)? |
Beta Was this translation helpful? Give feedback.
-
|
Just following up, the error message is telling you you don’t have liblldb-java.dylib, which means the build process failed - did you get “build successful” on steps 12 and 21? |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
d-millar, Have checked, and redone a few things. Commands taken fromm zsh history - git checkout release/14.x export LLVM_BUILD=/opt/homebrew/Cellar/llvm/15.0.2 Just realised path should really be /opt/homebrew/Cellar/llvm/15.0.2/lib Changed export LLVM_BUILD=/opt/homebrew/Cellar/llvm/15.0.2/lib export LLVM_HOME=/Users/michaelflynn/src/llvm-project Repeated (12) Build successful. Uh-oh - just came back and ran env JAVA_HOME is /Library/Java/JavaVirtualMachines/temurin-18.jdk/Contents/Home. (18) /opt/homebrew/Cellar/llvm/15.0.2/lib/liblldb.dylib plus 2 others from old vscode? "Task :Debugger-swig-lldb:linkMainMac_x86_64SharedLibrary FAILED Build now OK. (22) OK Error messages - java.library.path => opt/homebrew/Cellar/llvm/15.0.2:/Users/michaelflynn/src/ghidra_10.1.5_PUBLIC/Ghidra/Debug/Debugger-swig-lldb/build/os/mac_arm_64/lib Tried changing launch properties to VMARGS=-Djava.library.path=opt/homebrew/Cellar/llvm/15.0.2/lib:/Users/michaelflynn/src/ghidra_10.1.5_PUBLIC/Ghidra/Debug/Debugger-swig-lldb/build/os/mac_arm_64 Now debugger connects. All I have to do is figure out how to learn how to use it in Ghidra. Thanks for all your help. I think I documented the changes I made to your excellent instructions. I have probably have a different setup, and it seems that sometimes /lib is required here but not there, etc. By the way, the lldb in /cellar/llvm/15.0.2/bin is actually lldb-1400.0.30.3 Thanks once again. |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
Nicely done! Apologies regarding the VMARGS. I had forgotten about the different directory layout for the brew install. There’s a note to that effect in the instructions in the Debugger-swig-lldb directory, but it slipped my mind until you mentioned it. I did not realize that the brew 15.0 corresponded to lldb 14. Was wondering how you had gotten the gradle to work with the 14.x checkout and the 15.0 libraries, but that explains it. Seems like an odd choice on the brew folks’ part. To get started with the debugger, you can either launch the current program from the tool bar or start an lldb agent from the Targets’ window, and then launch the program from the Objects’ window. Let us know if you get stuck or if various windows fail to load. Again, congrats - you picked a challenging place to start! |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
The 10.1-beta release notes say "Currently, some effort is required on the user's end to clone, patch, and build LLDB with language bindings for Java. Once done, the new connectors for LLDB can be used in the normal fashion". @d-millar, are there instructions for how to do this someplace?
Beta Was this translation helpful? Give feedback.
All reactions