Ghidra debugger throws exceptions when debugging STM32F103 target though OpenOCD and StlinkV2

EDIT: For those who bump into the same issue and don’t want to scan through the comments, follow these steps to fix it. Add following lines to a text file and source it from Ghidra GDB window. You have to source them from a file as running define info proc mappings requires interactive input which Ghidra GDB console doesn’t support yet:

set arch armv7
set arm fallback-mode thumb
set arm force-mode thumb
define info proc mappings
echo 0x0 0xFFFFFFFF 0x100000000 0x0 mem \n
end
tar ext :3333

The last line points to the default OpenOCD gdb port. Tweak if you need to. The last step to link the Dynamic and Static listings is to open the Modules window and hit the static mapping button on it. Clicking it will start tracking the current execution point in the Listings and Decompiler window. That’s it.

END EDIT

When trying to connect to the local OpenOCD instance via IN-VM GDB local debugger, a couple things happen: The GDB window shows several errors right after I connect to the OpenOCD via target ext :3333:

Remote debugging using :3333
 warning: No executable has been specified and target does not support
determining executable automatically.  Try using the "file" command. 
 0x08002b26 in ?? ()
 (gdb) 0x08002b26 in ?? ()
 Not supported on this target.
 Not supported on this target.

The “Debug Console” pane immediately shows following errors:

 Could not list regions. Using default. | [] | Mon Jun 13 20:49:12 PDT 2022
 Listener ghidra.app.plugin.core.debug.gui.objects.DebuggerObjectsProvider$MyObjectListener@7084cb38 caused exception processing attributesChanged | [] | Mon Jun 13 20:49:12 PDT 2022
 Could not list regions. Using default. | [] | Mon Jun 13 20:49:12 PDT 2022

The “Objects” pane does show the stack and registers. Every other window stays in its default state - all of them are empty and the Listings pane in scrolled to the entry point. Hitting “Step into” or “Step Over” buttons makes more of the same errors appear in both the GDB logs and the “Debug Console”

To Reproduce

1. Launch OpenOCD
2. Load the debugged binary in the Debugger.
3. Create the new debugging connection via IN-VM local GDB. I’m using gdb from gcc-arm-none-eabi-10.3-2021.10 package
4. In the debugger console type tar ext :3333
5. Witness the errors above.

Expected behavior No errors, functional Stepping, generally other windows behaving as if the target is connected to.

Screenshots

Attachments If applicable, please attach any files that caused problems or log files generated by the software.

Environment (please complete the following information):

• OS: Ubuntu 21.04
• Java Version: OpenJDK 64-Bit Server VM (build 17.0.1+12-Ubuntu-121.04, mixed mode, sharing)
• Ghidra Version: 0.1.4
• Ghidra Origin: The official GitHub release

Additional context Using the gdb in console works totally fine, with the following .gdbinit and using the same exact gdb binary that I’m pointing Ghidra to, I’m able to step through the assembly without any errors:

tar ext :3333
tui enable
layout asm
monitor reset halt

[nsadeveloper789]

OK, so except for the “…caused exception processing attributesChanged”, all of these are pretty normal errors for a remote target. I suspect we can still ignore that one, though. As an aside, I’d take GDB’s advice and use the “file” command, if you have the image on disk. The errors about “Not supported on this target” and “Could not list regions” are typical for remote targets. We use “info proc mappings” to obtain a process memory map, but remote targets don’t support it, so it just falls back to one or two entries covering the entire address space. The other behaviors are all symptoms of not having a “recording.” We’re actively working on relaxing this requirement, but it seems Ghidra was unable to identify the remote platform. It’s pretty straightforward to fix. We’ll try remedies in this order:

1. Manually set the architecture from gdb
2. Manually set the architecture from Ghidra
3. Modify Ghidra to recognize your target

To get started, expand the “Environment” node in your “Objects” tree. Note the values for os and arch (debugger should be “gdb”). You can also type show os and show arch into the “Interpreter” window, if you prefer.

1. If arch is not what you expect, then disconnect and reconnect Ghidra to gdb, set the arch, then reconnect to the remote. If that works, then we’re all done. Just remember to set your arch each time or add it to your .gdbinit. Sometimes setting it to something more specific will help Ghidra, even if it appears to have no affect on GDB.

2. If that didn’t work, then in the “Objects” pane, select Inferior 1, right-click and select “Record.” It should present a langauge/platform selection box. Choose the one that best matches your platform and hit OK. If you have a choice between “ARM/GDB for…” and “Default GDB for…,” choose the former. If that worked, then you might consider proceeding to step 3 to make it automatic in the future. If it didn’t work, then let us know.

3. Edit Ghidra’s ARM.ldefs file (should be Ghidra/Processors/ARM/data/languages/ARM.ldefs). In there you should see external_name attributes which provide a mapping from Ghidra’s languages to GNU/GDB’s arch names. Presumably there is no entry which exactly matches what show arch reports for your target. Find the Ghidra language that worked from step 2 and add the appropriate external_name element to it, restart Ghidra, then retry connecting to your target.

[nsadeveloper789]

Yes, please leave it open. We’ll close it once we decide what to do re/ the GdbModelTargetProcessMemory.java issue. Thanks!