Can't Connect to GDB Terminal #6107
Comments
|
If you could, we might need two pieces of information. First, what version of gdb.exe? And, second, if you run "gdb.exe -i mi2", what's the first line of output. (We're expecting something like '=thread-group-added,id="i1"'. |
|
@d-millar The version is 14.1 and the first line of the output is: |
|
OK, thanks - am going to have to do some poking around. At a guess, your gdb is more recent than what we've tested against, and the reply for one of the early commands is coming back with a format we're not expecting. Will have to consult with @nsadeveloper789. (Separate note: your version of the path with the double-backslashes should have been the one that worked.) |
|
I've personally tried gdb 14.1 on Linux, but had some hang-ups. I was able to get connected, though. That said, it'd be worth trying with an earlier version if you can. I'd recommend 13.2. Because you're on Windows, you'll definitely need to add There is also a checkbox regarding line endings. Make sure yours indicates CRLF (DOS-style) line endings. (You might as well try it both ways, but in theory, MinGW requires CRLF.) Also, to @d-millar's point. Please check for the very first line of output when you run If none of that works, we can enable some logging for better diagnostics:
|
|
@nsadeveloper789 I did that, but it's not giving any great details about the exception, all I am getting in the log is this:
I tried with version 13.2 and that also didn't work. I also tried installing other versions like 11 through 12 and those versions don't work at all, only versions which would actually run was the packages for mingw-w64-x86_64-gdb-13.2-3 and mingw-w64-x86_64-gdb-14.1-1, everything else didn't run. Also, there is no warning or errors when calling gdb -i mi2. |
|
So, I take it the log outputs you're showing are from the 14.1-1 and 13.2-3 packages? The fact that the log believes it's CLI instead of MI2 indicates one of two things AFAIK.
I apologize for asking a third time, but please confirm, when you run or only: or something else? It might help to paste a screenshot of this experiment. Also, if you don't mind, please run it from a vanilla Windows command prompt, not the MSYS2 terminal (no bash). |
|
@nsadeveloper789 I get this when I run
Also, I did try to do |
|
@d-millar Any progress figuring why this issue is or any temporary workaround? |
|
Am hoping @nsadeveloper789 has some ideas on this. Unfortunately, am out of town for a week without a laptop. |
|
I'm scraping the bottom of the barrel here, unfortunately. I get the following when I run Notice the very first line it outputs is the
For item 1, just double-check your launcher config. For item 2, you'd need to set up a dev environment and place a breakpoint at |
|
@nsadeveloper789 I get this when I do gdb -i mi2:
|
|
This reminds me of #5698 (comment) |
|
@Nemoumbra Yes, it is similar, which is why we're trying to get at the first line. @tehomen I'm glad to see the first line is the event. Still, we're seeing something different in the log than we're seeing when you run gdb in isolation. My recommendations are still the same: 1) Please double-check the command line in your gdb launch config from Ghidra. (I don't suspect it's that simple, but I want to double check before going into the deep end.) If that doesn't fix it, you may need to 2) do some debugging of Ghidra itself on your end to see why those arguments aren't getting passed to gdb. Otherwise, you'll be waiting for us to try to replicate your environment to reproduce the issue, but it's not a priority for us. We're focused on getting Trace RMI going, which ought to overcome this issue.... |
|
Met the same issue with GDB via SSH (Linux), And in GDB.log, I could only see several lines like
Update, run The whole output is: |
|
I've got a little extra time today. I may obtain a copy of gdb-14.1 and see if I can reproduce this. I'm surprised to see the same problem via SSH. It Works on My Machine (TM), but I'm still using 13.1. |
|
Here's what I've tried so far: I've built and install gdb-14.1 on Linux, then using our development branch of Ghidra, I connected to it in a variety of ways: With and without I'm now in the process of obtaining gdb-14.1 (mingw64) on Windows. I already had gdb-13.1 installed, and it worked fine with Ghidra 11.0 (with |
|
Okay, It Works on My Machine (TM) for gdb-14.1 in Windows as well. I'll do my best to capture everything I did in case you want to try repeating it on your end: I'm using MSYS2 with mingw64. I'll refrain from screencapping my system's "About" dialog, but I'm on Windows Server 2019, which is closest to Windows 10 as far as consumer editions go. First, I installed (upgraded) to mingw64/mingw-w64-x86_64-gdb version 14.1-1. I just did this using
Then, I checked that I can invoke it from the vanilla command prompt with
Then I launch Ghidra 11.0 and use the Targets window to create a connection to gdb and configure it accordingly:
Note the path has the doubled
Going back: I can get it to malfunction by unchecking the DOS line endings box. If I do, it'll hang in the Connect dialog with a "Connecting...." status message indefinitely. However, my GDB.log is still showing MI2 output, not CLI: So, this is not what you've observed. Alternatively, if I keep DOS line endings but remove the |
|
Now I use Is that because I use Ghidra on Windows and connect to remote GDB via SSH (which is a Linux OS)? |
|
GDB via SSH to Linux should work with or without that workaround. Not sure why Ghidra is having trouble running GDB on its own (i.e., without new-ui) on your setup. In some ways, that workaround is actually nicer, because you get to keep the proper CLI. |
|
I too have this problem and report it. I think this is as expected, since the second line of the command shows
I also checked the logs by giving
And this is the log of ghidraDebug.bat "C://msys64//opt//devkitpro//devkitA64//bin//aarch64-none-elf-gdb.exe -i mi2"
I don't know if this is the cause, but my machine is Win10 and ja-JP language. |
|
Wow. Thank you for the thorough write up! So, the bit that catches my eye (finally), is the log line for ghidraDebug.bat:
I'm guessing I'll need to implement the FWIW, I don't think the ghidraDebug.bat thing is necessary. It just happens that you included the log for it, and it had the clue. If you're able to spin up a development environment, could you make the following changes and try again? diff --git a/Ghidra/Debug/Debugger-agent-gdb/src/main/java/agent/gdb/manager/impl/GdbManagerImpl.java b/Ghidra/Debug/Debugger-agent-gdb/src/main/java/
agent/gdb/manager/impl/GdbManagerImpl.java
index 413613b91b..a1d897325c 100644
--- a/Ghidra/Debug/Debugger-agent-gdb/src/main/java/agent/gdb/manager/impl/GdbManagerImpl.java
+++ b/Ghidra/Debug/Debugger-agent-gdb/src/main/java/agent/gdb/manager/impl/GdbManagerImpl.java
@@ -165,7 +165,7 @@ public class GdbManagerImpl implements GdbManager {
}
catch (Throwable e) {
terminate();
- Msg.debug(this, channel + "," + interpreter + " reader exiting because " + e);
+ Msg.debug(this, channel + "," + interpreter + " reader exiting because ", e);
//throw new AssertionError(e);
}
}
diff --git a/Ghidra/Framework/Pty/src/main/java/ghidra/pty/windows/AnsiBufferedInputStream.java b/Ghidra/Framework/Pty/src/main/java/ghidra/pty/windows/AnsiBufferedInputStream.java
index 047489a664..4c573815b9 100644
--- a/Ghidra/Framework/Pty/src/main/java/ghidra/pty/windows/AnsiBufferedInputStream.java
+++ b/Ghidra/Framework/Pty/src/main/java/ghidra/pty/windows/AnsiBufferedInputStream.java
@@ -270,6 +270,14 @@ public class AnsiBufferedInputStream extends InputStream {
execSetGraphicsRendition();
mode = Mode.CHARS;
break;
+ case 'h':
+ execPrivateSequence(true);
+ mode = Mode.CHARS;
+ break;
+ case 'l':
+ execPrivateSequence(false);
+ mode = Mode.CHARS;
+ break;
}
}
@@ -473,4 +481,9 @@ public class AnsiBufferedInputStream extends InputStream {
// TODO: Maybe a callback. Otherwise, don't care
titleBuf.clear();
}
+
+ protected void execPrivateSequence(boolean enable) {
+ // These don't matter for input buffering.
+ escBuf.clear();
+ }
}The first change is only temporary and should give us better diagnostics if my guess turns out to be wrong, or if there are more issues. The remaining changes implement what I think are the missing ANSI codes. Thanks! |
|
I already think my guess is off. The private commands have a question mark in them, and I already have code that's supposed to handle that. So, either the exception is not about the command I think it is, or that code is broken. My next suggestion, again assuming you set up a dev environment, is to tell Eclipse to break on |
|
I added those codes and they connected to the target. |
|
Well. Okay then! I guess I'll merge the change. I'm still a bit mystified as to why, but I guess unless I can get a hold of the same build of Win10, I won't be able to see what its ConPty is producing. Thanks for giving it a try, and I'm glad it's working now. |
ryanmkurtz
added
Status: Internal
Whenever I try to connect to GDB I get this exception:
ghidra.dbg.error.DebuggerModelTerminatingException: Error while starting GDB: Pty implementation does not support null
sessions. Try C:\msys64\mingw64\bin\gdb.exe -i mi2
I've tried running it with -i mi2, I've also tried where I write the path like this:
C:\\msys64\\mingw64\\bin\\gdb.exe
Nothing works.
I am running this on Windows 10.
The text was updated successfully, but these errors were encountered: