Replies: 52 comments 10 replies
-
|
Were you specifically trying to build the |
Beta Was this translation helpful? Give feedback.
-
|
My main goal is to be able to debug apps on Apple silicon. That said, to get the lldb debugger working is what I would like to achieve. |
Beta Was this translation helpful? Give feedback.
-
|
Unfortunately, I’m not near my computer for the next few days, but I’ve seen this error before. I believe (and take this with a grain of salt) the issue is that the homebrew installation lacks the files needed to build, so your value for LLVM_HOME is probably incorrect. Of note, homebrew version 15 is llvm 14 in their github repo, so you should not have to do the “gradle generateSwig” step. Those files are likely to be ok, as is. That said, you may still need LLVM_HOME to be set correctly for the “gradle build” step. If you can, checkout the rep from the source distribution, “git checkout release/14”, and then set the LLVM_HOME variable to that location. You may also have to fiddle a bit with the LLVM_BUILD var to make sure it’s at the correct position. |
Beta Was this translation helpful? Give feedback.
-
|
OK, on my computer, which, I should say, is an M1 not an M2, but I was able to reproduce your issue exactly. My steps: The problem, I believe, is that lldb is under constant development, and that "release/14.x" and the homebrew code are not an exact match. The code included with our distribution was generated using SWIG from "release/14.x". You could presumably do the same for homebrew base, but the homebrew directories do not appear to include the SWIG binding files, i.e. macros.swig, headers.swig, and interfaces.swig. It might be interesting to download just the bindings from the llvm-project source, drop them in the homebrew directories (where exactly?), and regenerate the SWIG files using "build generateSwig", but that is not an experiment I have tried. Also, not quite clear what it buys you, as you still have to clone the llvm source repo. (I should point out that step 2a in the instructions is in this case extraneous, as lldb has already been build for you.) Let us know if the build still fails after downloading the llvm repo, of course. |
Beta Was this translation helpful? Give feedback.
-
|
My current status is that I use the plain Ghiddra 10.2.2 version, the homebrew installed llvm, and go directly in the Debbuger-swig-lldb instructions. From what I understand, I need to perform 2b to get the debugger-swig-lldb up and running. Is this correct? |
Beta Was this translation helpful? Give feedback.
-
|
These are the error messages when I try to debug without running the instructions in "InstructionsForBuildingLLDBInterface.txt": |
Beta Was this translation helpful? Give feedback.
-
|
You need to do 2b if your version of lldb is not a match for the version we used to generate the base set of SWIG files. For the current release, this is "release/14.x". Did you run "git checkout release/14.x" after cloning? |
Beta Was this translation helpful? Give feedback.
-
|
I did. I just checked both, the LLVM_HOME and if checked out the right version. It still shows the same error. |
Beta Was this translation helpful? Give feedback.
-
|
Looks like in your error message that you are executing "gradle generateSwig" from .../Debugger-swig-lldb/llvm-project - that seems incorrect. |
Beta Was this translation helpful? Give feedback.
-
|
I saw that and corrected it. The error is as shown above. Not sure what else I can try to do. Maybe it is worthwhile to try to use llvm-project like shown in 2a. I‘m open for any suggestion. |
Beta Was this translation helpful? Give feedback.
-
|
Have you definitely installed swig? |
Beta Was this translation helpful? Give feedback.
-
|
I thought I had, I reinstalled swig by using "brew install swig". Now the error message has changed: |
Beta Was this translation helpful? Give feedback.
-
|
OK, well, that's progress - try "gradle clean" or manually deleting bin/src/llvm-project/lldb/bindings/java, i.e. you may be getting duplicates from bin/src and src. |
Beta Was this translation helpful? Give feedback.
-
|
I like that you call it progress :) Running 'gradle clean' doesn't change anything. Removing the Debugger-swig-lldb/src/llvm-project/lldb/bindings/java folder leads to this error: |
Beta Was this translation helpful? Give feedback.
-
|
Ah, oops - should have been clearer. You want one copy, but you wanted the "src" set - not the "bin/src". mv bin/src to src and remove bin/src (or re-pull if that's easier). (Sorry, this is so compplicated!) |
Beta Was this translation helpful? Give feedback.
-
|
I have a fix - it's not a good fix in the sense that I have no idea what its implications are, but it's a fix. The fix is: |
Beta Was this translation helpful? Give feedback.
-
|
@d-millar awesome that worked! Thank you so much for all your help. I'm stuck at another error message while playing with the debugger. However, I guess this is just me not knowing yet what I'm doing wrong.
Anyway, thanks for the great support, I'm not used to that level of support at all 👍 |
Beta Was this translation helpful? Give feedback.
-
|
Sigh - the challenges of debugging on macos.... So, that error is telling you that you don't have adequate permissions to debug that process. How does one get adequate persmissions you are probably wondering. Well, I know of three approaches: (1) You could reboot in macos Recovery mode, from a terminal issue the command "csrutil enable --without debug", and reboot again. I have to admit I've only ever done this once. Seems a little extreme for most debugging scenarios. If none of these things work, there might be an issue with the codesign Authority for your version of java. (Hopefully not, but you could check that using "codesign -dv --verbose=4 path_to/java" |
Beta Was this translation helpful? Give feedback.
-
|
I tried 3 but the result is still the same, meaning the same error in the debug console. |
Beta Was this translation helpful? Give feedback.
-
|
My understanding of the details of debugging permission is a little incomplete, but let me describe my current understanding.... For you to debug a process, the following have to be true: Requirement (1) should be pretty easy to test. Requirement (2) is most easily tested by debugging a program you've written, e.g. write a HelloWorld.cpp program, compile it, and try to debug it with lldb. If that works, try debuggin it with Ghidra. Requirement (3) usually means the target is recognized by the system as coming from a legit source, but option (3) above tries to solve this if not. I would try debugging the target with lldb before using Ghidra to test (3). To your question regarding option [2] vs. [3] above, if the program doesn't have "debuggable" permissions, neither [2] nor [3] will work. Requirement (4) generally means you belong to the group "admin" or "_developer" on your box. If you are admin, you can run (or have someone with admin run) "sudo dseditgroup -o edit -a UUU -t user _developer" to add you to the "_developer" group. Regarding what "codesign -dv" should show, well, I'm always a little unclear on that point. At a minimum, it should be signed using a certificate that is valid for debugging, e.g. "Apple Root CA" with "Authority=Code Signing" and a valid sha256 hash. With a little luck, you can run a few tests, and we can narrow down the problem. |
Beta Was this translation helpful? Give feedback.
-
|
Hmm, I thought I would be smart to install macOS inside a virtual box and build Ghidra there to debug anything after running "csrutil enable --without debug". However, I still get the same "SBTarget is invalid" console message. I expected that in this setup, it should work out of the box but no. |
Beta Was this translation helpful? Give feedback.
-
|
Sorry to hear that as that's a fair amount of work you just put in. That said, it's going to be harder to solve the problem without knowing exactly what the problem is. Steps I would take: (1) Verify that you can run the target. (4) If you cannot run the target, make sure you've granted it permission to execute in the Security settings. (6) If you cannot run any program in lldb, check your "groups" settings. (11) If you can run the test program in lldb but not target but the target runs normally, the problem is probably with how the target executable is signed, and we'll need to look into that. |
Beta Was this translation helpful? Give feedback.
-
|
@riegaz any luck? |
Beta Was this translation helpful? Give feedback.
-
|
Getting "ld: library 'c++' not found" on M1 using: gradle build |
Beta Was this translation helpful? Give feedback.
-
|
@Jagden Might need a few more clues. Am assuming you've "git clone"d Ghidra, run "gradle -I gradle/support/fetchDependencies.gradle init", run "gradle buildGhidra", set JAVA_HOME, LLVM_HOME, and LLVM_BUILD, cd'd to Ghidra/Debug/Debugger-swig-lldb, then run "gradle build" and got the error (or done the last three in the latest 11.0 distribution) - yes? What version of lldb do you have? Is the LLVM_HOME pointing at release/16.x? Have you tried commenting out the mac_x86_64 target in gradle.buildNatives (or gradle.build)? What version does "c++ --version" return? |
Beta Was this translation helpful? Give feedback.
-
|
EDIT: Found the problem. Tried: git clone https://github.com/llvm/llvm-project.git It always fails. In older xcode the output was: My setup: Grade: Gradle 8.0.2 c++ --version Using gradle -d build, "/usr/bin/ld" -demangle -lto_library /usr/local/lib/libLTO.dylib -dynamic -dylib -arch arm64 -platform_version macos 13.0.0 13.0.0 -mllvm -enable-linkonceodr-outlining -o /opt/utils//ghidra_10.2.2_PUBLIC/Ghidra/Debug/Debugger-swig-lldb/build/os/mac_arm_64/liblldb-java.dylib -L/opt/utils//llvm-project/cmake/lib -install_name liblldb-java.dylib /opt/utils//ghidra_10.2.2_PUBLIC/Ghidra/Debug/Debugger-swig-lldb/build/objs/main/shared/mainCpp/b6954r4kxxfhmnzbfiaa1erun/LLDBWrapJava.o -llldb -lc++ -lSystem ld: library 'c++' not found removing -c++ flag then yields: ld: library 'System’ not found |
Beta Was this translation helpful? Give feedback.
-
|
@Jagden i am facing same issue, like you do, have any clue to fix it? |
Beta Was this translation helpful? Give feedback.
-
|
@Jagden Excellent - nice catch. I will modify the InstructionsForBuildingLLDBInterface.txt to reflect that. No reason to install llvm (unless you don't have lldb, which seems unlikely). Just a heads up, I think 10.2 has the swig files for release/14.x, while 11.0 has them for release/16.x. As you may have surmised, the "gradle generateSwig" step is only necessary if you have a mismatch. |
Beta Was this translation helpful? Give feedback.
-
|
@Jagden Which issue are you still facing? Is your environment a mess because of doing the "ninja install"? Are you trying and unable to compile the swig/lldb bindings? Or are you just trying to get Ghidra to build? If the first, did the fix you mentioned ("The fix was to run in the llvm-project/cmake: xargs rm < install_manifest.txt which restored my xcode clang, after that everything worked as expected and build succeeded.") not work? If the second, we're recommending you NOT use the JNI/swig approach and rely on the newer python interface. If the third, removing the LLVM_HOME should skip this step. I thought we had cleaned up our documentation on this, but, looking at it now, it seems to have regressed. Apologies for that! |
Beta Was this translation helpful? Give feedback.
-
|
@d-millar i have the exact same issue, let me try @Jagden ways but what do you think should be a proper fix? |
Beta Was this translation helpful? Give feedback.
-
|
@akshar001 apologies, I misinterpreted who was posting. I would use @Jagden‘a fix or reinstall xcode to reset clang. At that point, remove LLVM_HOME and build Ghidra. Use the traceRMI versions detailed in the debugger docs if you need to use the debugger. |
Beta Was this translation helpful? Give feedback.
-
|
@d-millar i have tried to use, it But i get this error somehow while building build-natives. rapJava.cpp:274:10: fatal error: 'lldb/lldb-public.h' file not found |
Beta Was this translation helpful? Give feedback.
-
|
OK, so just to be clear, you've decided to stick with the JNI/swig implementation and not use the python-based version - is that correct? |
Beta Was this translation helpful? Give feedback.
-
|
Yes, JNI/swig for now not python-based version, i tried to re-compile llvm from scratch made sure it has lldb, removed all other llvm links and versions from brew, xcode and yet i it's giving and lldb error. |
Beta Was this translation helpful? Give feedback.
-
|
OK, what version of llvm/lldb are you using? What have you set LLVM_HOME and LLVM_BUILD to? Did you re-generate the SWIG files for your version? Did you modify build.gradle or buildNatives.gradle to reflect the llvm directory structure? |
Beta Was this translation helpful? Give feedback.
-
|
@d-millar |
Beta Was this translation helpful? Give feedback.
-
|
Wow, OK - so looks like you're building against llvm/lldb v19. As may be obvious to you by now, that's a completely untested configuration. I would strongly recommend (assuming you don't want the python version) to build against the 17.x release version. I can attempt to build against 19 at some point, but that's pretty low priority given we're deprecating this build process. Keeping the SWIG source consistent with the rapidly changing lldb source is something of a nightmare and for better or worse the python env is much saner. |
Beta Was this translation helpful? Give feedback.
-
|
I understand, i'll try 17.x |
Beta Was this translation helpful? Give feedback.
-
|
@d-millar and anyone coming back to this issues, this is what i have done for now. Major problem that i had was related to -lsystem, somehow it wasn't linking to it, And i added manually this path, Into many buildGradle or buildNativesGradle wherever -lsystem error was flagging, and it worked. |
Beta Was this translation helpful? Give feedback.
-
|
@akshar001 Glad to hear you got it working - and thanks for detailing how you got there. May help the next person in the queue. This has been an ongoing issue for us. Not only variations in the code as llvm/lldb change versions, but the variety of possible installations methods and configurations. Am hoping the python-based approach alleviates some of these headaches, although frankly python configuraion comes with its own set of headaches. |
Beta Was this translation helpful? Give feedback.
-
Dear All,
I do have trouble building Ghidra on my M2 Macbook.
I downloaded the latest version of Ghidra.
lldb -version shows:
brew install llvm installs llvm 15.0.5
This is the error I get after setting the following parameters:
The LLVM_HOME path was adjusted in the
build.gradlefile from$llvm_dir/lldb/includeto$llvm_dir/includeas the path differs in the brew installed llvm version.Errors:
Could you point me in the right direction?
Beta Was this translation helpful? Give feedback.
All reactions