Replies: 42 comments 109 replies
-
|
@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.
-
|
Hmmmm, not sure I've ever seen that, so no quick answer, but a few points to keep in mind: (1) Both lldb and gdb statically link to the python libraries when they're compiled, so you have to use the version of python they were built with. For the current CLion, I believe that's 3.10.7, but you can check it by starting up lldb and issuing the commands: "script", "import sys", and "sys.version". (2) The CLion version of lldb does not appear to support either "pip" or loading python classes from PYTHONPATH. I believe the only other alternative is to put the relevant modules in your path. It probably also makes sense to do this with python itself. I have not used "settings set plugin.python executable" and really have no sense of how lldb finds libraries if you go that route. (3) Am assuming your target is 32-bit from the various refs above - if not, using the 32-bit debuggers will be a problem. (4) What version of protobuf did you install? Per our instructions, it has to be 3.20.3. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for detailed explanation, thing learned. And yes |
Beta Was this translation helpful? Give feedback.
-
|
Hmmm, well, not sure if you've tried this yet, but maybe, as a sanity check, try debugging a relatively mundane 64-bit process, like, say, notepad.exe. |
Beta Was this translation helpful? Give feedback.
-
|
I just compiled 32bit of my executable and yes indeed I am connected to the debugger. |
Beta Was this translation helpful? Give feedback.
-
|
The error suggests you're timing out on the connection back to Ghidra, i.e. "ghidra trace connect" is failing. At a guess, this is because "target create" is failing. If you launch TaskManager or the equivalent, are you seeing your target in the process list? Also, if you aren't already, use "support/ghidraDebug.bat" in place of "ghidraRun.bat" and see if there anything suggestive of an error in the terminal. |
Beta Was this translation helpful? Give feedback.
-
|
I created a fresh install copied all libraries and it's all working now by default. I think the root problem (beside my lack of knowledge in the topic) was that With all the libraries copied
|
Beta Was this translation helpful? Give feedback.
-
|
Maybe. Without the actual executable, would be hard for me to tell. You're getting an access violation, presumably dereferencing a null pointer. LdrInitShimEngineDynamic is frequently used to trap on library accesses, e.g. CreateRemoteProcess or LoadLibrary, so could very well be and anti-debugger thing. If you can locate the call in the target, you could try nop'ing it out, but.... |
Beta Was this translation helpful? Give feedback.
-
|
Ok thank you for the follow ups |
Beta Was this translation helpful? Give feedback.
-
|
Well I don't know what's going on but yet again I have the same problem :) Even with the "normal" applications. Something is odd here |
Beta Was this translation helpful? Give feedback.
-
|
What does "normal" mean here? notepad.exe? self-compiled example code? 64-bit / 32-bit? LLVM lldb or CLion lldb? |
Beta Was this translation helpful? Give feedback.
-
|
I keep receiving this error even with Edit: This is a breakpoint exception right? 0x80000003 |
Beta Was this translation helpful? Give feedback.
-
|
Hmmmm, that’s a 32-bit address in notepad.exe. Do you have a 32-bit version of notepad.exe or are you debugging notepad with the 32-bit version of LLVM’s lldb. Also, 0x80000003 is a breakpoint. If you resume, what happens? |
Beta Was this translation helpful? Give feedback.
-
|
Yes its 64bit notepad. |
Beta Was this translation helpful? Give feedback.
-
|
Not sure I understand what you mean by an additional ENTER in the terminal, I’m afraid. The normal behavior for “—stop-at-entry” would be the process breaks at the initial breakpoint. You hit the resume button or “continue” in the terminal, and notepad is now running. To resume activity in the debugger, you’ll need to hit break. And, yes, any other debugger is a better choice in Windows. The obvious choice would be to use windbg or from Ghidra dbgeng. |
Beta Was this translation helpful? Give feedback.
-
I suppose... let me try... 🔢 |
Beta Was this translation helpful? Give feedback.
-
|
Re breakpoints, it appears that you have 5 sessions running simultaneously. This is not a good idea. From the Connections window, I would “Close all” and start again. With 5 sessions running, you have very little idea which ones are active and which have died. |
Beta Was this translation helpful? Give feedback.
-
|
I went into documentation but my |
Beta Was this translation helpful? Give feedback.
-
|
Do you have the WIndows SDK (i.e. the debugger) installed? |
Beta Was this translation helpful? Give feedback.
-
|
You can't install |
Beta Was this translation helpful? Give feedback.
-
|
From dist |
Beta Was this translation helpful? Give feedback.
-
|
It's running! But requires pybag 2.2.12 dshikashio/Pybag@2.2.12...2.2.14 ghidra/GhidraDocs/InstallationGuide.md Line 165 in 684ed5e |
Beta Was this translation helpful? Give feedback.
-
|
I wonder how do i deal with missing windows |
Beta Was this translation helpful? Give feedback.
-
|
It's so painful Ghidra doesn't properly remember debugging targets ... and when editing |
Beta Was this translation helpful? Give feedback.
-
|
Apologies re 2.212, pybag was upgraded right before the release and the fix apparently did not make it in. The version in master will work with 2.2.14. I’m a little confused about the pywin32 requirement - my recollection is that replaces win32 and is only needed by 2.2.14. Will look into that tomorrow. Re symbols, they can be downloaded from Microsoft directly, but do you need them? Sorry this has been so traumatic - it really shouldn’t have been, and I feel your pain. We moved to the python model because of all the insanity involved with JNI, but we’ve definitely traded one version of insanity for another. Your patience and help hunting down bugs is greatly appreciated. |
Beta Was this translation helpful? Give feedback.
-
|
So, normally, if the launch succeeds, all the parameters are saved in the program database for that program. Do you have a program loaded in the Static Listing window? The fact that you had to delete the “image-opt env” line suggests you do not (which would account for the options being greyed out). If you don’t have a program, the debugger effectively has no place to save the settings. Re escaping, the same tricks from the local-lldb.bat may work. (Yours is the first time oddly we’ve hit this.) In particular, you may combinations of single and double quotes. I have to crash now, but will tackle this first thing in the morning. |
Beta Was this translation helpful? Give feedback.
-
|
I will share my opinion:
Same window should be reused for renaming existing entries.
|
Beta Was this translation helpful? Give feedback.
-
|
Hmmm I don't know how do I pass |
Beta Was this translation helpful? Give feedback.
-
|
Seems like the correct path to debugger may be |
Beta Was this translation helpful? Give feedback.
-
|
But this error? |
Beta Was this translation helpful? Give feedback.
-
|
Re "-c", the windbg command line options are not exposed (AFAICT) in the dbgeng API. The easiest thing to do is put them in a startup script and execute this from the terminal. Re "correct path", close - |
Beta Was this translation helpful? Give feedback.
-
|
If I am debugging 32 bit, what is the correct way here? |
Beta Was this translation helpful? Give feedback.
-
|
When using Error caused by front end
Traceback (most recent call last):
File "C:\Users\buk\Documents\Tools\GHIDRADEBUGGER\ghidra_11.3_PUBLIC\Ghidra\Debug\Debugger-rmi-trace\pypkg\src\ghidratrace\client.py", line 65, in _handle_invoke_method
result = self.client._handle_invoke_method(request)
File "C:\Users\buk\Documents\Tools\GHIDRADEBUGGER\ghidra_11.3_PUBLIC\Ghidra\Debug\Debugger-rmi-trace\pypkg\src\ghidratrace\client.py", line 1146, in _handle_invoke_method
return method.callback(**kwargs)
~~~~~~~~~~~~~~~^^^^^^^^^^
File "C:\Users\buk\Documents\Tools\GHIDRADEBUGGER\ghidra_11.3_PUBLIC\Ghidra\Debug\Debugger-agent-dbgeng\pypkg\src\ghidradbg\methods.py", line 274, in refresh_registers
tnum = find_thread_by_regs_obj(node)
File "C:\Users\buk\Documents\Tools\GHIDRADEBUGGER\ghidra_11.3_PUBLIC\Ghidra\Debug\Debugger-agent-dbgeng\pypkg\src\ghidradbg\methods.py", line 140, in find_thread_by_regs_obj
return find_thread_by_pattern(REGS_PATTERN0, object, "a RegisterValueContainer")
File "C:\Users\buk\Documents\Tools\GHIDRADEBUGGER\ghidra_11.3_PUBLIC\Ghidra\Debug\Debugger-agent-dbgeng\pypkg\src\ghidradbg\methods.py", line 127, in find_thread_by_pattern
find_proc_by_num(pnum)
~~~~~~~~~~~~~~~~^^^^^^
File "C:\Users\buk\Documents\Tools\GHIDRADEBUGGER\ghidra_11.3_PUBLIC\Ghidra\Debug\Debugger-agent-dbgeng\pypkg\src\ghidradbg\methods.py", line 72, in find_proc_by_num
if id != util.selected_process():
~~~~~~~~~~~~~~~~~~~~~^^
File "C:\Users\buk\Documents\Tools\GHIDRADEBUGGER\ghidra_11.3_PUBLIC\Ghidra\Debug\Debugger-agent-dbgeng\pypkg\src\ghidradbg\util.py", line 292, in _func
return self.run(func, *args, **kwargs)
~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^
File "C:\Users\buk\Documents\Tools\GHIDRADEBUGGER\ghidra_11.3_PUBLIC\Ghidra\Debug\Debugger-agent-dbgeng\pypkg\src\ghidradbg\util.py", line 261, in run
return future.result(0.5)
~~~~~~~~~~~~~^^^^^
File "C:\users\buk\appdata\local\programs\python\python313\Lib\concurrent\futures\_base.py", line 449, in result
return self.__get_result()
~~~~~~~~~~~~~~~~~^^
File "C:\users\buk\appdata\local\programs\python\python313\Lib\concurrent\futures\_base.py", line 401, in __get_result
raise self._exception
ghidradbg.util.DebuggeeRunningException: Debuggee is Running |
Beta Was this translation helpful? Give feedback.
-
|
I haven't tried debugging on Windows using the x86 debugger for x86 targets in quite a while. Have a meeting to go to now, but will try it out after. The stack trace above will always occur if you attempt anything in the GUI that triggers a refresh while the process is running. When you say, "hangs in wow64.dll" are you hitting an exception? I guess I'm not entirely sure what that means. |
Beta Was this translation helpful? Give feedback.
-
Could this exception indicate this? Just idea!
It's first place where breakpoint is hit, but trying to resume just loops over the |
Beta Was this translation helpful? Give feedback.
-
|
To your longer list of observations, I agree on some; others are a little more problematic. I am reminded of the words of a salesman in Akihabara who, when asked why the Japanese version of a camera had 200 buttons while the otherwise identical American version of the camera had 2, replied "Americans don't like buttons?". Many of the things you've mentioned have been considered, but there always a trade-off. Tools occupy screen real estate, and real estate is limited. For every button, you add to the Toolbar, space for some other feature is removed. Similarly, while one might prefer a choice as to when your options gets saved, do you really want to hit "Save" every time? Re saving parameters, I should have been a little clearer. The parameters are saved unless the start-up fails catastrophically. For instance, if I run dbgeng with "C\Windex\notepad.ex" and "Arguments: junk", after the launch fails, I can re-open the dialog and fix "C:\Windex\notepad.ex" to "C:\Windows\notepad.exe". With respect to items in the launch menu, if you really want options not to appear in the "Configure and launch" menu, you can move them out of data/debugger-launchers. Similarly, if you want to customize them or add your own, these files are trivially editable. You can change the field label, the default value, the description, or the hover for any of the options. I do agree we should probably add documentation to this affect in the help. Right now, it's documented in GitHub in the GhidraClass under "B5-AddingDebuggers". On your point regarding greyed out options, when the underlying API supports connecting without an executable, we do try to enable that. For instance, you can start any of the gdb options without an executable in the listing. The dbgeng API does not support this except when starting via "attach" or debugging a kernel. That said, we should change the behavior along the lines of lldb, i.e. bring up the dialog and allow the user to specify the target on -the-fly. I will put in a ticket for that. Re "missing dlls", I'm not sure I understand the reference. If you have a chance, maybe more details on this? As you've noted, the scripting API already has the ability to add menu options. If you're feeling motivated, send us a script with the adds you think would be helpful. If it seems generally useful, we'd definitely consider adding it to the distribution. And, finally (I think - I've probably missed something), the current help does describe what you need for each launcher in the correspinding "Setup" section. I'm a little loath to include specifics like URLS for downloading as these vary over time and by platforms, but, if you have specific suggestions regarding these sections, send them our way! |
Beta Was this translation helpful? Give feedback.
-
That's great.
I am trying to find where
I have yet no idea about this part, I only seen it in the script manager. But ill consider later.
When asked about grayed out option you said, quote:
|
Beta Was this translation helpful? Give feedback.
-
|
Ah, right! I missed the boat on that. |
Beta Was this translation helpful? Give feedback.
-
|
OK, following up, I don't think using the x86 versions of the various dbgXXX.dll's is a good idea. The problem is that Java and pybag are going to load some of these before you get to the load corresponding to the entry in the startup dialog, and, if the versions are mismatched, well, things won't work and they won't work in ways that are completely non-obvious. I will think about a workaround (you could conceivably use windbg in client/server mode), but for now I would say stick to x64. Wow.dll is essentially proxying the system calls for you, i.e. your target makes a 32-bit syscall and wow.dll converts it to the corresponding 64-bit call. In general, this should have very little affect on debugging the target. That said, it probably introduces an extra breakpoint on start-up, similar to the initial breakpoint for every debuggee. i.e. you'll hit 0x80000003, resume, hit 0x4000001f, resume, and then be running. If that's not the case for your executable, I'd be interested, although I can't say off the top of my head why that could happen. If you want to disable the exception generally, that's do-able from the Terminal. This article does a better job than I could explaining how: https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/controlling-exceptions-and-events |
Beta Was this translation helpful? Give feedback.
-
|
Ok ill take a read - but generally - I must work with the native debugger on the module-level? Ex. I cannot tell |
Beta Was this translation helpful? Give feedback.
-
I had to click "resume" in |
Beta Was this translation helpful? Give feedback.
-
|
Why I cannot set breakpoints - I get this exception? |
Beta Was this translation helpful? Give feedback.
-
|
Again, because the target is running. The dbgeng API does not allow you to set breakpoints while the target is running. |
Beta Was this translation helpful? Give feedback.
-
Oh ok, so any command to debugger is a refresh. |
Beta Was this translation helpful? Give feedback.
-
|
The buttons in the toolbar are enable/disabled based on the state of the target, and the state of each thread is listed in Threads. If you want to see the state in the Model Tree, you can also select "Show hidden". And the terminal does not display a prompt when the process is running. Just to be clear, 0x4000001f from wow is an exception, not a breakpoint. Software breakpoints are generally module-specific. Hardware breakpoints are not. Exceptions are not module-specific, so you can set them off or on, but not on-by-module. |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
::@title gdb
::@image-opt env:OPT_TARGET_IMG
::@desc <html><body width="300px">
::@desc <h3>Launch with <tt>gdb</tt></h3>
::@desc <p>
::@desc This will launch the target on the local machine using <tt>gdb</tt>.
::@desc For setup instructions, press <b>F1</b>.
::@desc </p>
::@desc </body></html>
::@menu-group local
::@icon icon.debugger
::@help TraceRmiLauncherServicePlugin#gdb
::@enum StartCmd:str run start starti
::@enum Endian:str auto big little
::@env OPT_TARGET_IMG:file="" "Image" "The target binary executable image"
::@env OPT_TARGET_ARGS:str="" "Arguments" "Command-line arguments to pass to the target"
::@env OPT_GDB_PATH:file="gdb" "gdb command" "The path to gdb. Omit the full path to resolve using the system PATH."
::@env OPT_START_CMD:StartCmd="starti" "Run command" "The gdb command to actually run the target."
::@env OPT_ARCH:str="auto" "Architecture" "Target architecture"
::@env OPT_ENDIAN:Endian="auto" "Endian" "Target byte order"
@echo off
set PYTHONPATH0=%GHIDRA_HOME%\Ghidra\Debug\Debugger-agent-gdb\pypkg\src
set PYTHONPATH1=%GHIDRA_HOME%\Ghidra\Debug\Debugger-rmi-trace\pypkg\src
IF EXIST %GHIDRA_HOME%\.git (
set PYTHONPATH0=%GHIDRA_HOME%\Ghidra\Debug\Debugger-agent-gdb\build\pypkg\src
set PYTHONPATH1=%GHIDRA_HOME%\Ghidra\Debug\Debugger-rmi-trace\build\pypkg\src
)
IF EXIST %GHIDRA_HOME%\ghidra\.git (
set PYTHONPATH0=%GHIDRA_HOME%\ghidra\Ghidra\Debug\Debugger-agent-gdb\build\pypkg\src
set PYTHONPATH1=%GHIDRA_HOME%\ghidra\Ghidra\Debug\Debugger-rmi-trace\build\pypkg\src
)
set PYTHONPATH=%PYTHONPATH1%;%PYTHONPATH0%;%PYTHONPATH%;C:\Users\buk\Documents\Tools\GHIDRADEBUGGER\ghidra_11.3_PUBLIC\Ghidra\Debug\venv\Lib\site-packages
IF "%OPT_TARGET_IMG%"=="" (
"%OPT_GDB_PATH%" ^
-q ^
-ex "set pagination off" ^
-ex "set confirm off" ^
-ex "show version" ^
-ex "python import ghidragdb" ^
-ex "set architecture %OPT_ARCH%" ^
-ex "set endian %OPT_ENDIAN%" ^
-ex "ghidra trace connect '%GHIDRA_TRACE_RMI_ADDR%'" ^
-ex "ghidra trace start" ^
-ex "ghidra trace sync-enable" ^
-ex "set confirm on" ^
-ex "set pagination on"
) ELSE (
"%OPT_GDB_PATH%" ^
-q ^
-ex "set pagination off" ^
-ex "set confirm off" ^
-ex "show version" ^
-ex "python import ghidragdb" ^
-ex "set architecture %OPT_ARCH%" ^
-ex "set endian %OPT_ENDIAN%" ^
-ex "target exec "%OPT_TARGET_IMG%"" ^
-ex "set args %OPT_TARGET_ARGS%" ^
-ex "ghidra trace connect '%GHIDRA_TRACE_RMI_ADDR%'" ^
-ex "ghidra trace start" ^
-ex "ghidra trace sync-enable" ^
-ex "%OPT_START_CMD%" ^
-ex "set confirm on" ^
-ex "set pagination on"
) |
Beta Was this translation helpful? Give feedback.
-
|
Any chance to get |
Beta Was this translation helpful? Give feedback.
-
|
So the way to go now is providing empty image and typing the |
Beta Was this translation helpful? Give feedback.
-
|
Problem when executing |
Beta Was this translation helpful? Give feedback.
-
|
Working on this as we speak.... Re gdb, it looks like spaces in the Image work fine, but not in Arguments. However, I can get args to work if we add two lines before the IF: For exampe, I can launch windbg targetting windbg from gdb using: (Insanity noted.) |
Beta Was this translation helpful? Give feedback.
-
|
Another issue with |
Beta Was this translation helpful? Give feedback.
-
|
-ex "target exec 'C:/\Games/\some path- super/\game.exe'" ^ |
Beta Was this translation helpful? Give feedback.
-
|
|
Beta Was this translation helpful? Give feedback.
-
|
hmmm, that looks like the process died, i.e. the InvalidObjPathError's a very likely a result of the SIGSEGV |
Beta Was this translation helpful? Give feedback.
-
|
Nah. InvalidObjPathError is from trying to update an object's attributes (in Ghidra's database) before creating that object. I should probably have that error message include the path in question. This is one of those bugs that just keeps going away when we try to investigate.... |
Beta Was this translation helpful? Give feedback.
-
|
Re gdb, understood. Mingw doesn't implement "info proc modules" - try "Force Full View" from the Regions pull-down in the top right. |
Beta Was this translation helpful? Give feedback.
-
I am not sure about this one, it may be due to "attach" method. |
Beta Was this translation helpful? Give feedback.
-
|
re set new-console on, there is an option for that. I forget where it is - a box referencing tty? |
Beta Was this translation helpful? Give feedback.
-
|
re new-console from docs: This is probably outdated as there's no checkbox I can see anywhere. |
Beta Was this translation helpful? Give feedback.
-
|
re escaping this seems like working also for empty image. setlocal enabledelayedexpansion
-ex "target exec '!OPT_TARGET_IMG:\=\/!'" ^ |
Beta Was this translation helpful? Give feedback.
-
|
The "Inferior TTY" checkbox is available but only on Linux (and maybe macOS). On those systems, you can open a pty, and the child end gets a filename that you can then give to |
Beta Was this translation helpful? Give feedback.
-
|
Ah, this one I think I know off the top of my head.... If you leave the Image blank and run lldb (or run something and kill it), you'll get the Terminal and an entry in the Connections window, but basically nothing else. Then run "process attach --pid XYZZY" to attach. You''ll see the usual messages in the Terminal, but nothing else. Double-click the entry in Connections, double-click the noname node that appears. This should partially populate the Model Tree. Now, refresh Processes (right-click) and double-click one of the threads. Should bring you to an almost normal state. "Force Full View" again if you need to. Yes, I realize this is a liitle crazy and certainly not obvious. The issue again surrounds another unfortunate trade-off. When you attach, the process stops but doesn't send any event we can trigger a refresh off of. There are workarounds, but most of the ones we've tried involve pushing refreshes on other events, which then slows down the normal behavior. sigh |
Beta Was this translation helpful? Give feedback.
-
|
Ok... I tried and indeed it seems like working but
Exception in batch operation: TraceRmiError('ghidra.app.plugin.core.debug.service.tracermi.TraceRmiHandler.InvalidObjPathError')
(gdb) Python Exception <class 'gdb.MemoryError'>: Cannot access memory at address 0x0And this one when trying to breakpoint on read Traceback (most recent call last):
File "C:\Users\buk\Documents\Tools\GHIDRADEBUGGER\ghidra_11.3_PUBLIC\Ghidra\Debug\Debugger-rmi-trace\pypkg\src\ghidratrace\client.py", line 65, in _handle_invoke_method
result = self.client._handle_invoke_method(request)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\Users\buk\Documents\Tools\GHIDRADEBUGGER\ghidra_11.3_PUBLIC\Ghidra\Debug\Debugger-rmi-trace\pypkg\src\ghidratrace\client.py", line 1146, in _handle_invoke_method
return method.callback(**kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\Users\buk\Documents\Tools\GHIDRADEBUGGER\ghidra_11.3_PUBLIC\Ghidra\Debug\Debugger-agent-gdb\pypkg\src\ghidragdb\methods.py", line 608, in break_read_range
gdb.execute(
gdb.error: Expression cannot be implemented with read/access watchpoint.
Watchpoint 3: -location *((char(*)[27]) 0x6bb2d070) |
Beta Was this translation helpful? Give feedback.
-
|
OK, will put a ticket in for that one. |
Beta Was this translation helpful? Give feedback.
-
|
Regarding each error mentioned:
|
Beta Was this translation helpful? Give feedback.
-
|
Thanks for follow up I already lost this rabbit hole but if I encounter them again ill get back here. |
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