nsadeveloper789
commented
2 years ago 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:
- Manually set the architecture from gdb
- Manually set the architecture from Ghidra
- 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.
lolwheel
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 mappingsrequires interactive input which Ghidra GDB console doesn't support yet: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:The "Debug Console" pane immediately shows following errors:
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
gdbfromgcc-arm-none-eabi-10.3-2021.10packagetar ext :3333Expected 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):
Additional context Using the
gdbin console works totally fine, with the following.gdbinitand using the same exactgdbbinary that I'm pointing Ghidra to, I'm able to step through the assembly without any errors: