GDB via SSH debugging fails for Linux targets with no symbol tables

[cseagle]

Describe the bug Ghidra debugger fails to launch Linux executables that have no symbol table.

To Reproduce Steps to reproduce the behavior:

1. Compile a program on Linux
2. Strip the resulting binary
3. Attempt to debug the binary using Ghidra / Debug via SSH
4. See error

Expected behavior GDB has no problems debugging stripped binaries, I would not expect Ghidra to.

Screenshots Example error message:

<GDB/MI2 -exec-run --start> caused '{msg=[No symbol table loaded. Use the "file" command.]}' agent.gdb.manager.impl.cmd.GdbCommandError: <GDB/MI2 -exec-run --start> caused '{msg=[No symbol table loaded. Use the "file" command.]}' at agent.gdb.manager.impl.GdbPendingCommand.checkCompletion(GdbPendingCommand.java:226) at agent.gdb.manager.impl.cmd.MixinResumeInCliGdbCommand.completeOnRunning(MixinResumeInCliGdbCommand.java:59) at agent.gdb.manager.impl.cmd.AbstractLaunchGdbCommand.complete(AbstractLaunchGdbCommand.java:53) at agent.gdb.manager.impl.cmd.AbstractLaunchGdbCommand.complete(AbstractLaunchGdbCommand.java:23) at agent.gdb.manager.impl.GdbPendingCommand.finish(GdbPendingCommand.java:71) at java.base/java.util.concurrent.CompletableFuture$AsyncRun.run(CompletableFuture.java:1804) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) at java.base/java.lang.Thread.run(Thread.java:833)

---

Build Date: 2022-Jul-26 1543 EDT Ghidra Version: 10.1.5 Java Home: C:\Program Files\Java\jdk-17.0.1 JVM Version: Oracle Corporation 17.0.1 OS: Windows 10 10.0 amd64 Workstation: DESKTOP-N4MPK5G

Attachments N/A

Environment (please complete the following information): See error output above

Additional context N/A

[nsadeveloper789]

Because your local system is Windows and the remote Linux, I suspect it's a matter of the executable path not lining up when you use the Quick Launch button. You'll need to use the menus instead (hopefully just once) so that you can configure the remote executable path:

Debugger - > Debug [your program] -> In GDB via ssh

The first form is for the connection, which is probably already filled correctly. Once connected, it should present a second form asking for the target executable path. That should be its path on the remote system. IINM, Ghidra will memorize that, so once you have it working from the menus, it should work from the Quick Launch button from then out.

[cseagle]

Thank you, I am quite confident that it is not a path issue. Among other things I am not using the quick launch button and Ghidra can successfully debug unstripped Linux binaries from Windows using GDB via SSH. Perhaps you have followed the steps to reproduce?

[nsadeveloper789]

Yes, I did, but I'll try again. The only way I was able to reproduce the message you got was for the "file" command to fail.

Can I get a bit more information about the remote Linux system? Distro version and GDB version, please.

[nsadeveloper789]

A couple more bits of info that might help diagnose the issue:

1. Can you paste the contents of the "Interpreter" window after attempting to launch?
2. The example error you give in the description: Where does that error message appear? In an error popup dialog, or in the error log / console?

[nsadeveloper789]

Another shot in the dark: When prompted for the target executable path, there should also be a checkbox to "use starti." Enable it. It still doesn't explain the error message you got, but at the moment, it's the only thing I can think you'd need when you strip the target.

Some background: You won't get an initial break for a binary without "main," even if you have breakpoints placed in Ghidra. Ghidra issues breakpoint commands by address, so it has to launch the target, interrogate GDB for the memory map, then issue the (possibly relocated) breakpoints. To ensure the target doesn't terminate before interrogation, you have to use "starti" or it has to have a "main."

Alternatively, you can connect to GDB via SSH using the "Targets" window, then use the "Interpreter" window to place breakpoints and launch your target as you would normally do in GDB.