Replies: 15 comments
-
|
@NeoZ16 It is possible, but not in the way that you're attempting. The option names confuse a lot of people, and we're open to suggestions as to how to make it clearer if you have any.... So, just by way of background, the purpose of the GADP agents is two-fold: (1) to prevent crashes in the native debugger clients from taking down the Ghidra Java VM, and (2) to enable scenarios where the host platform on which you're running Ghidra proper does not support the native libraries required by the debugger. For example, you could run Ghidra locally on a macos host and connect to a Ghidra agent that wraps the dbgeng API on a remote Windows machine. Your scenario is not actually that. Why - because the lldb or gdb server you're starting up in the Android VM does not speak GADP, which is our custom protocol. Gdbserver, the lldb debugserver, and lldb-server all speak variants of Remote Serial Protocol (RSP), a protocol developed originally for gdb only but adopted by various platforms. We have atttempted direct comms using RSP in the past, but that road is fraught with peril to say the least. RSP is basically a suggestion, not a standard, and the variations in its implementation make direct RSP comms unmanageable. That said, you have several options that should work, although I will caveat this with the comment that many of the lldb options, in particular, have bugs in the current release. You may be better off building from source if that is an option. So,options: We have done some preliminary work on a JDWP client for Dalvik, but it's definitely in need of some care and feeding, so caveat emptor there. Let us know if you run into trouble with any of the above. We're interested in this as a use case and eager to iron out bugs. |
Beta Was this translation helpful? Give feedback.
-
|
@d-millar As for the names, yes I think that I was confused me. I just reread the documentation and if I would've read it a little bit more carefully I think I could've avoided that mistake. Also maybe having some example that shows the how using the IN-VM option and the interpreter could help. Maybe I overlooked it, but I couldn't really find any examples or tutorials for this. |
Beta Was this translation helpful? Give feedback.
-
|
Agreed - the docs could definitely stand more detailed examples. Appreciate the feedback! |
Beta Was this translation helpful? Give feedback.
-
|
@d-millar Any idea what the reason for this could be? |
Beta Was this translation helpful? Give feedback.
-
|
@NeoZ16 Hmmm, that's almost but not quite the error in #4884. Did you get any errors during the swig build process (see Ghidra/Debug/Debugger-swig-lldb/InstructionsForBuildingLLDBInterface.txt)? |
Beta Was this translation helpful? Give feedback.
-
|
@d-millar Im not building myself. I downloaded 10.2.2 from the GitHub Release. |
Beta Was this translation helpful? Give feedback.
-
|
@NeoZ16 For lldb to work, you HAVE to build the code yourself unless your version is an exact match for the liblldb.dylib and lldb installed on your box. |
Beta Was this translation helpful? Give feedback.
-
|
more specifically, you have to run "gradle generateSwig" and "gradle build" in Ghidra/Debug/Debugger-swig-lldb after setting the relevant environment variables. |
Beta Was this translation helpful? Give feedback.
-
|
@d-millar |
Beta Was this translation helpful? Give feedback.
-
|
@NeoZ16 Apologies - I definitely need to learn to be more explicit in my answers.... First off, you do NOT need to rebuild Ghidra from source to get the lldb interface working, but you DO need to build the JNI wrapper, i.e. you need to build the portion of Ghidra that lives in Ghidra/Debug/Debugger-swig-lldb. That said, if you wish to build Ghidra from source, I would do that first, i.e. don't set LLVM_HOME, run "gradle -I gradle/support/fetchDependencies init", run "gradle build", and make sure everything else is working first. Before building the lldb piece, I would also recommend reading the InstructionsForBuildingLLDBInterface.txt file a couple of times (it's a little confusing) and maybe looking through some of the relevant posts in Issues and Discussions, e.g. #4937. To your specific case, LLVM_HOME needs to be set to the source repository for lldb. You do NOT have to build llvm/lldb, but I would highly recommend cloning the relevant repos, checking out "release/14.x", and setting LLVM_HOME to the root of that project. LLVM_BUILD can point either to a local build of lldb or any install via apt or brew, but should be where "lib/liblldb.so" or "lib/liblldb.dylib" lives. JAVA_HOME, of course, should point to where Java lives, on Linux typically something like "/usr/lib/jvm/java-17-openjdk-amd64", i.e. it contains "bin/java". Once you have the env variables set, you need to run "gradle generateSwig", copy or move the resulting files per the instructions (depending on whether you're in a distro or source), and the "gradle build". Let us know if you get stuck! |
Beta Was this translation helpful? Give feedback.
-
|
@d-millar So the library is compiled now and I actually got the IN-VM lldb session.
But this option does not even show for me. Is this a version problem? (I'm still using build 10.2.2 downloaded from the releases page.) |
Beta Was this translation helpful? Give feedback.
-
|
@NeoZ16 Hmmm, yes, I had thought the option made it into 10.2.2, but apparently not. 10.2.3 is imminent (for some definition of imminent), or, if you're feeling brave, you can build from Ghidra from the current source (which has the option added). The big issue is that, unlike with gdb, you have to do a little finagling to get the Interpreter started for a remote connection, and without that you have no way of starting the connection. If you want to go the build route, the instructions on the GitHub page are pretty straightforward - certainly clearer than the SWIG instructions which you've already survived! :) |
Beta Was this translation helpful? Give feedback.
-
|
sigh - I think I was wrong about the changes making it into 10.2.3. You may have to try the source. |
Beta Was this translation helpful? Give feedback.
-
|
Ok thanks, then I'll probably try and do that! |
Beta Was this translation helpful? Give feedback.
-
|
Just to confirm, 10.2.3 won't resolve the problem (10.3 should, but...). You will probably have to build from source to get the benefit of recent changes. This is pretty straightforward, but yell if you get stuck. |
Beta Was this translation helpful? Give feedback.
-
I'm trying to use the debugger to connect to an lldb or gdb server.
Does not really matter which one at the moment.
Server is running in a Android VM and connecting with a lldb or gdb session does work.
I tried using the local agent via GADP/TCP option with the Agent interface adress and Agent TCP port set to the values that I used for testing if connecting works at all.
But this does not work. Even if I do not start the remote server it crashes with this message:
Could not connect: java.lang.RuntimeException: Agent terminated with error: (DebuggerConnectDialog).I feel like I'm misunderstanding something here. Is connecting to a debugging server even possible?
Beta Was this translation helpful? Give feedback.
All reactions