Source layout

[mumbel]

@d-millar @nsadeveloper789

Just an open question, was just messing around with the debugger for the first time really, just a qemu-system with a bare metal RISC-V elf (https://github.com/TrustworthyComputing/csaw_esc_2020/blob/master/qual-esc2020.elf). Was attempting to use gdb-multiarch and then (gdb) target set architecture riscv , (gdb) target remote :1234. Didn't get too far and just started reading through some of the source, wasn't a real attempt more of just a wonder what happens.

Where do you see the source layout moving once things settle down? Obviously the supported architectures are at different levels and usages. I noticed the architecture specifics are a little different for ARM, probably coded out a bit more due to your mac preference and supported OS/technologies. The package <-> classes match for like MIPS/PPC/M68K/x86 and then flipped for ARM, with the arm package. Which I didn't trace down how those get treated any differently since its not in the same package as the other architectures.

Do you think some of that code would ever end up in Ghidra/Processors/ and then those gradle include api project(:Debugger) (right?) if they want? (Would that support out of tree modules?)

[d-millar]

@mumbel If I read your comment correctly, you're talking about the mismatch between Ghidra processor architecture descriptions and the descriptions provided by gdb's "set architecture"? Or did I miss the point? Not sure what you mean by "out of tree modules". If you can elaborate, happy to discuss!

[mumbel]

That was just a side thought. Mostly just relates to if Ghidra/Processor/ would ever get debugger source or not. If there was a separate repo with just a processor module (ie copied out Skeleton/) if they implemented the GdbMipsDebuggerMappingOpinion equivalent in the right src package, and installed that processor module, that'd get picked up and usable by the debugger tool (which if that works then I'd assume it'd be fine in Ghidra/Processor/)?

edit: is there any difference between having it in either of these locations:

• ./Debug/Debugger/src/main/java/ghidra/app/plugin/core/debug/platform/gdb/GdbMipsDebuggerMappingOpinion.java
• ./Processors/MIPS/src/main/java/ghidra/app/plugin/core/debug/platform/gdb/GdbMipsDebuggerMappingOpinion.java

[d-millar]

Ah, gotcha! Yes, that seems like a reasonable approach. Will raise it at the next meeting, get folks' thoughts. We do need a way to address the variant MappingOpinions issue. (Adding a ticket as I type - thanks!)

[nsadeveloper789]

These "MappingOpinion" files should be deleted along with the deprecated debugger object model stuff.