Debugger not working for bare mips target.

[nicolasnoble]

Describe the bug
In ghidra 10, I haven't been able to successfully use the debugger meaningfully while targeting a raw MIPS CPU (PlayStation 1)

To Reproduce

1. Download a self-contained version of PCSX-Redux.
2. In ghidra, load openbios.elf that's provided with the Windows version of PCSX-Redux.
3. In PCSX-Redux, go to Emulator->Settings, Disable the Dynarec CPU, and activate the Debugger, as well as the GDB server. Set the "BIOS" image file to the corresponding openbios.bin from the same folder you got openbios.elf, and proceed to hard reset the emulator:
   
4. Use ghidra's debugger tool to connect to gdb-over-gdap, and the binary /usr/bin/gdb-multiarch (often present in many Linux distributions).
5. In the Debugger's "Interpreter" window, type target remote localhost:3333 to connect to the gdb server.
6. --> Only "step in" works. No breakpoint can be placed, registers view won't work.

Expected behavior
We should be able to see registers, place breakpoints, and trace through code generally.

Screenshots
Here, you can see that, despite placing a breakpoint at bfc00164, no breakpoint is listed on the left "Objects" panel. You can also see that no register is being listed in the right "Registers" panel.

Environment (please complete the following information):

• OS: Ubuntu 21.04
• Java Version: 15.0.3
• Ghidra Version: 10.0
• Ghidra Origin: official ghidra website

Additional context
PCSX-Redux has a special option that can dump the gdb protocol in the logs. It's clearly visible there that ghidra isn't even trying to set any sort of breakpoint command. On the other hand, registers are clearly being pulled from the emulator to gdb/ghidra. There is also a window that lists the available breakpoints set by gdb, and none were set.

There are some warning / errors in ghidra, but I have no clue whatsoever what they mean or how they came to be, as it's fairly opaque in its interaction with gdb here.

Note that I am the author of PCSX-Redux, and I can make any sort of change I want to the gdb server in order to help ghidra work it out. It has been reported to me that IDA is perfectly able to connect to it and will happily trace / place breakpoints, and gdb-multiarch itself is perfectly happy to drive it too.

[mumbel]

from release notes

Debugging user-mode Windows applications on x64 hosts via dbgeng.dll/WinDbg (including 32-bit x86 applications via WoW64)
Debugging user-mode Linux applications on amd64/x86_64 hosts via GDB (including 32-bit i686/x86 applications)

[nicolasnoble]

from release notes

Debugging user-mode Windows applications on x64 hosts via dbgeng.dll/WinDbg (including 32-bit x86 applications via WoW64)
Debugging user-mode Linux applications on amd64/x86_64 hosts via GDB (including 32-bit i686/x86 applications)

Except this seems to be working with Game Boy Advance using bare-ARM at the moment? https://wrongbaud.github.io/posts/ghidra-debugger/

This doesn't seem very consistent overall.

[nicolasnoble]

Would it be linked to #3071 ?

[d-millar]

from release notes

Debugging user-mode Windows applications on x64 hosts via dbgeng.dll/WinDbg (including 32-bit x86 applications via WoW64)
Debugging user-mode Linux applications on amd64/x86_64 hosts via GDB (including 32-bit i686/x86 applications)

Except this seems to be working with Game Boy Advance using bare-ARM at the moment? https://wrongbaud.github.io/posts/ghidra-debugger/

This doesn't seem very consistent overall.

LOL - if you're expecting consistency from gdb, you need to spend more time looking at its internals! We're working toward presenting a consistent interface to the user, but honestly gdb is less an API than a general set of guidelines that each project may or may not choose to follow. As the author of PCSX-Redux, am sure you've had some exposure to this.

Also, per @mumbel's comment, for the moment we're really only trying to support local user-mode Linux and Windows applications. That said, if you're willing to work with us, we'd like to take a stab at fixing whatever issues you're hitting up against.

So, first off, #3071, yes. Also, #3161, #3153, #3102, #3074, #2974, #2908, #2859, and the entire Discussion entitled "Connect to luma3ds..." are probably relevant. Sorry, a lot of reading.

Might help us first, though, to diagnose your specific problem. So, judging from the screenshots you sent, the trace is not active. All of the window except the Objects view and the Interpreter are driven by the trace. So, if the trace isn't working, you'll see mostly empty windows. As mentioned in some of the other posts, e.g. #3161 and #3071, and as you correctly surmised, the typical root cause for the trace not working is lack of support for "info proc mappings". Does this work from the Interpreter for you? If not, you'll need to modify the define_info_proc_mappings script and run it from the Interpreter. (Yes, this is a crappy solution - we're working on it.)

Am a bit surprised that you're not seeing the breakpoints you set in the Objects tree. Try selecting the root of the tree and hitting "Refresh". It may be that the requests are timing out and leaving you with empty nodes, a problem we've seen with slower connections.

I realize @wrongbaud's post probably set your expectations a bit high. He deserves some serious credit for the time he put into that blog entry. He worked through some very rough bits with almost nothing to go on int terms of documentation.

Keep us posted, and let's see what we can do!
Best,
D

[d-millar]

Oh, hey, just realized something else - you set the breakpoint on the static listing, yes? That breakpoint is a proper gdb logical breakpoint in the sense that it’s set and stored with the program, but the breakpoint only gets set on the target when the static image is mapped to memory. This is consistent with the other problems you are seeing, i.e. caused by the lack of a trace. Try setting the breakpoint in the Interpreter window - my guess is it will appear in the Objects view. If so, we can concentrate on getting the trace running. With luck, the breakpoint issue will resolve with it.

[wrongbaud]

from release notes

Debugging user-mode Windows applications on x64 hosts via dbgeng.dll/WinDbg (including 32-bit x86 applications via WoW64)
Debugging user-mode Linux applications on amd64/x86_64 hosts via GDB (including 32-bit i686/x86 applications)

Except this seems to be working with Game Boy Advance using bare-ARM at the moment? https://wrongbaud.github.io/posts/ghidra-debugger/

This doesn't seem very consistent overall.

Hey guys, just wanted to clarify a few things about that post.

There were major inconsistencies across GDB versions and emulator versions, meaning that only subsets of certain features would work based on which combination of these two things I was using. For example - some versions of of GDB would provide register information and not be able to set breakpoints, and other versions would do the opposite. There is a small table at the end of the post under "Extra Information / Notes" that explains this.

Note that I don't think any of these things were Ghidra related - but more a byproduct of the GDB stub that was in use by the emulator itself.

LOL - if you're expecting consistency from gdb, you need to spend more time looking at its internals! We're working toward presenting a consistent interface to the user, but honestly gdb is less an API than a general set of guidelines that each project may or may not choose to follow. As the author of PCSX-Redux, am sure you've had some exposure to this.

This pretty much sums it up :)

[nicolasnoble]

Thanks a lot for the pointers, this gives me starting points to look at. I'll keep you updated.