How to use all the available Ghidra Debugger options?

[Nemoumbra]

I want to discuss the related stuff here. But first and foremost, I've run into some weird bugs with the first option: gdb.

The "stack trace":

com.sun.jna.LastErrorException: GetLastError() returned 2
---------------------------------------------------
Build Date: 2023-Jul-11 1640 EDT
Ghidra Version: 10.3.2
Java Home: k:\Shared_storage\Data\JDK19\jdk-19.0.2
JVM Version: Oracle Corporation 19.0.2
OS: Windows 10 10.0 amd64

This happened when I entered the path to my local MinGW GDB and tried to connect. For context, that's how it looks like:

I find it very odd that replacing gdb.exe with lol.exe doesn't change anything.
The platform is... Oh wait, the "stack trace" already has this info.

[d-millar]

Wow, ok - that is spectacularly uninformative. :)

The immediate thing that confuses me is the JNA error, given our implementation of the gdb agent doesn't use JNA directly. Any chance you could walk me through the exact steps you took? I.e. did Targets->Connect throw this error immediately? One thing to try for sure - try using double-slashes in your path (Java is not a fan of the backslash).

[Nemoumbra]

Steps to reproduce:

• launch Ghidra, open the project, open the executable in the Debugger Tool

• click here:
  

• the window "Connect" (check the last message here for the image) appears where I select the option to be gdb

• enter the unescaped path and click "Connect"

(By the way, I've noticed that the checkbox for some reason is now missing its bottom border... No matter what I do, I doesn't appear back...)

But let's do things one step at a time.

Now let me explain what happens when I escape the path.
If the path is bogus (leads to lol.exe), the error stays the same!
If I escape the path to GDB, the error goes away and gets replaced by a new one (yay!)

ghidra.dbg.error.DebuggerModelTerminatingException: Error while starting GDB: Pty implementation does not support null 
sessions. Try k:\msys64\mingw64\bin\gdb.exe -i mi2

You may think that the problem's over, but nope. First of all, the error message is deceiving (the backslashes are once again unescaped).
Second of all, when I enter k:\\msys64\\mingw64\\bin\\gdb.exe -i mi2, it tells me

ghidra.dbg.error.DebuggerModelTerminatingException: Error while starting GDB: Could not detect GDB's interpreter mode. 
Try k:\msys64\mingw64\bin\gdb.exe -i mi2

As a user, I'm confused since that's what I entered. I mean, I think that's what I entered.

Now then, in case you'd be interested to see the responses to k:\msys64\mingw64\bin\gdb.exe -i mi2, "k:\\msys64\\mingw64\\bin\\gdb.exe -i mi2" and "k:\\msys64\\mingw64\\bin\\gdb.exe" -i mi2.

The first one goes back to the GetLastError crap, the second one produces a super funny output

ghidra.dbg.error.DebuggerModelTerminatingException: Error while starting GDB: Could not detect GDB's interpreter mode. 
Try k:\msys64\mingw64\bin\gdb.exe -i mi2 -i mi2

The last one just removes the redundant quotes. Quoting the unescaped path doesn't work.

[d-millar]

Ah, right - you jogged my memory. Apologies for not remembering this right off the bat - the issue is the lack of Pty support on Windows.

I'd suggest checking out the previous issues #2908 and #3102)in Issues, and #2721 in Discussions. The basic workaround is to use the "GDB over SSH" agent rather than "IN-VM GDB" and either a WSL client or separate Linux VM running a gdbserver. Definitely, too complicated by half, but....let us know if neither of those will work for you or if you get stuck.

[Nemoumbra]

I don't suppose that has anything to do with the GetLastError blasphemy, the checkbox glitch or the incorrect launch suggestion.
As for the Pty support... Is this the Windows GDB implementation issue or the WinAPI one? I'm curious how no one tried the ConPTY approach in the last 2 years and the broken option was (and is) just hanging around.
Well, I'm also a bit confused why you're telling me

rather "IN-VM GDB"

Is this how you're calling gdb in the source code? If so, I couldn't know that.

Lastly, about my current options... If I understood that correctly, I can't use the first of the GDB-related agents as of now. This leaves me with the SSH one and the called gdb via GADP. Why not the GADP, does it face the same issue? I'm kinda unwilling to launch WSL as it was very hungry for my RAM the last time I tried using Docker for Windows. Technically, it doesn't matter that much... I've also got a Linux VM and it's not so lightweight as well.
Alright, let's say I've managed to launch either of them and stuff some GDB inside (this time it's gonna be not the MinGW one but a standard GNU tool). I'm concerned about how this GDB will be able to debug an app that I'm working with here, on Windows. I hope you didn't assume I'm trying to debug a Linux app here.

[d-millar]

Might actually be mistaken about this - Dan may have implanted the ConPty support. Will dig a little deeper tomorrow.

[d-millar]

OK, I think I've reproduced the error, but I'd like to confirm with you. If you run "k:\msys64\mingw64\bin\gdb.exe -i-mi2" from the cmd line, what is the first line of output? Am guessing it's some flavor of a python error message that doesn't begin with "=".

[Nemoumbra]

I think you meant -i mi2 (with the space). And no, you're mistaken. The line is =thread-group-added,id="i1".

[d-millar]

Hmmm, that's unfortunate. I still think we're close to the issue, but, on my machine, I get a line that doesn't begin with "=" whether I run gdb from cmd or Ghidra. I suppose there's some possibility your Ghidra environment differs from your cmd environment, but.... Basically, I think the logic is GdbManagerImpl::PtyThread:run (line 139 and ff) is a little weak. We default to CLI if the first line returned by gdb does not start with "=". There are many reasons why this could happen, e.g. gdb is accessed via a wrapper, gdb has a header in MI2 mode, or, as in my case, gdb throws an error when loading python.

I'm assuming you're running from the distribution versus Eclipse, and are probably not eager to debug our code. :)
I will attempt to see if there's some other way to test your environment and verify the root of the problem. In any case, am putting in a ticket for the run logic.

[Nemoumbra]

I'm running the last version from the Releases that I unpacked to my Ghidra versions storage (me when no updater). I would love to debug some Java if I knew how to.
By the way, the version of GDB is 13.1 and I've recently run pacman -Syu so it's the newest we've got.
The SHA-256 is caddd4a16df091791d3c088f2463e1c402631952d99ab872ce7f298d322aa269.
MD5 is 30df7d420f45604937ab25c35360762a.

Lastly... Any questions from here you can briefly answer?

[Nemoumbra]

Actually, you know what... I've got a guide on how to recreate my MinGW environment. I just followed the compiling guide for ImHex. The shell script for downloading stuff is this one. Maybe this will be helpful... Maybe not... I don't think I've ever installed something else cause the interface is very inconvenient and I'd rather not touch that thing at all.

[d-millar]

Ah, sorry....let me take a shot at the questions/comments:

(1) The "GetLastError blasphemy" is a direct result of the unescaped path, i.e. somewhere we pass your input through some bit of code that we probably shouldn't have and it insists on escapes. Putting in a ticket for that - @nsadeveloper789 has volunteered to take that one on.
(2) The checkbox glitch...I will have to ask around on that one.
(3) The incorrect launch suggestion: well, that would actually be a good suggestion if our code had correctly identified the problem. That's the problem am hoping to address first.
(4) ConPTY - well, I completety missed the boat on that, i.e. we've already added that code. Should have worked (and probably will if we solve (3))
(5) "IN-VM GDB" - apologies, and, yes, that is now just called "gdb". It used to be called "IN-VM GDB" because gdb was executed in the context of the current Java VM. This is slightly faster and more efficient than the other option, "gdb via GADP". "Gdb via GADP" spawns a second Java agent that runs gdb. This has the advantage of protecting any work you're doing in Ghidra proper, as native code errors will take down only the agent, not Ghidra proper. "Gdb vis SSH", as you've noted, launches a native copy of gdb in a Linux env via SSH.
(6) Re your issue, no difference between "gdb" and "gdb via GADP", except the latter is harder to debug.
(7) WSL and/or a Linux VM - yeah, I was off the mark there too. Most of our customers who are running gdb in Windows are interested in debugging remote targets with some flavor of a gdbstub. Your case is less common, and I made a bad assumption.

I think that's most of your questions - yell if I missed some.

With respect to debugging Java, if you're really interested, the "Advanced Development" section on the Ghidra GitHub main page has all the details. Short version: you would clone the public repo, run the init script to load dependencies, build Ghidra via Gradle, and then set up the debug environment in Eclipse. It's very straightforward and am happy to help if you're interested, but the build process does take awhile. Let me know if you decide you have time/interest and/or you get stuck on any of our instructions.

[Nemoumbra]

Alright, it's been 6 weeks (exactly). There were a few issues which I'm gonna restate now.

1. GetLastError weirdness (ticket assigned to nsadeveloper789)
2. The checkbox UI error
   3-4) The incorrect launch suggestion depends on the underlying bigger problem of not having the Windows PTY (ConPty) behave correctly (ticket assigned to someone).

What's the status update? Unfortunately, the release notes didn't help me deduce this info.

[d-millar]

Tickets are in for both #1 and #2 - are either of these stopping you from using the tool or are they basically annoyances?

[Nemoumbra]

I have found the time and motivation for building Ghidra. So far I've cloned the repo (no submodules), installed Gradle 8.5 and Eclipse IDE for Java Developers - 2023-12, then ran the gradle command to install additional dependencies.
gradle buildGhidra failed with the following error:

> Task :Utility:compileJava FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':Utility:compileJava'.
> error: invalid source release: 17

Is this error related to the Java VM version? If so, I'd like to mention that I didn't specify any installations myself. If it picked something wrong, I gotta fix that somehow.

[ryanmkurtz]

What is your output of gradle -v?

[Nemoumbra]

Gradle 8.5
------------------------------------------------------------

Build time:   2023-11-29 14:08:57 UTC
Revision:     28aca86a7180baa17117e0e5ba01d8ea9feca598

Kotlin:       1.9.20
Groovy:       3.0.17
Ant:          Apache Ant(TM) version 1.10.13 compiled on January 4 2023
JVM:          11.0.10 (JetBrains s.r.o 11.0.10+0-b96-7249189)
OS:           Windows 10 10.0 amd64

This output indeed shows it's attempting to use an outdated VM. I don't even know where it's located.

[ryanmkurtz]

On your %PATH% perhaps? Try javac -version.

[Nemoumbra]

Ok, I've modified my path, fully executed gradle buildGhidra and gradle prepdev eclipse buildNatives, then imported the project into the Eclipse workspace. It looks like I've got myself a Ghidra 10.5 DEV build! Now then...
Let me ask now how to debug stuff and how to launch the local version without Eclipse?

[d-millar]

For running w/o Eclipse, the relevant scripts live in Ghidra/RuntimeScripts/.

For debugging stuff:
(1) Launch the Debugger tool from the front-end.
(2) Import the executable you'd like to debug.
(3) From the toolbar, select the debugger relevant for your OS, e.g. "Debug xclock in GDB locally IN-VM"
(4) (OK, maybe this should be before (3)) Read the help and check out the course material in GhidraDocs.

[d-millar]

Oh, just occurred to me that wasn't what you were asking re debugging. From Eclipse's toolbar, run "Debug Ghidra". (You may have to import the Launchers if there's nothing adjacent to the bug icon.) Should switch to the debugger perspective, which has all the relevant step controls and breakpoint windows.

[Nemoumbra]

Oh yes, I'll just pretend you didn't write the first message (especially considering what this whole thread is about). Thank you for your assistance, maybe I'll be able to help now!
Incidentally, I see there's been a major release since I've cloned Ghidra today. Has anything been fixed from the list above? I've seen some GDB-related changes that didn't resemble anything of the sorts, but I've decided it'd be better to just ask away for confirmation. Anyway, I'm ready to debug stuff that isn't fixed yet.

Oh man, sorry, more questions... Why can't I use JDKs other than JDK 17? How can I get a project view over the java source files in Eclipse (so far I can only see a subset of the expected files).

[d-millar]

Yeah, sorry - that was pretty stupid on my part (answered without looking at the context).

I think the GetLastError stuff was fixed. There have been many, many changes, and I definitely would suggest trying things out again with 11 (although the may also be fixed in what you have) and seeing how it goes.

Re JDKs, various pieces of the code use features in the JDK not available before 17, so that's our official minimum. You can probably run with JDKs greater than 17, although last time I checked building from scratch with 21 had issues.

And, yes, your ProjectExplorer window looks incorrect. Let me see if I can reproduce what you have and figure out what went wrong. Thinking maybe you did the import from wrong level....guessing here. Maybe also, try changing your ProjectsPresentation to "Flat" (under three dots on top right).

[Nemoumbra]

It has only now occurred to me that Gradle does in fact pick the JDK from PATH. This sounds like a major inconvenience, because I've also got JDK 19 and I want to be able to use either of them. I can't keep all JDK paths in PATH because Gradle picks the first one it finds.

[Nemoumbra]

I have erased the whole git folder along with the Eclipse workspace, then rebuilt everything and reimported the project.

The project presentation is "Flat" now.

Is this alright now?

[d-millar]

That looks much better!