Implement Ghidra Importer

[stravant]

• Imports large amounts of function, variable, and structure information into a Ghidra project for the game.

• General approach: Configure with --debug to include full symbols information, run a build, and extract the DWARF debug information from the build to get information about functions / structs. Combine this information with the original addresses from symbols.txt to apply the extracted information to the original main.dol.

• If a compilation unit has debugging information present in the build executable (because it is marked as Matching in configure.py and gets linked), then full parameter name, return type, global variable, etc. information is imported for that compilation unit.

• All the structs, enums, and unions refenced in these Matching compilation units get imported. Even with only a small subset of the CIs matching, any given CI will generally reference a significant subset of the total struct types in the game, so we still get good coverage of the total set of structs.

• If a compilation unit is not marked as Matching, we fall back to demangling the symbol names in symbols.txt, and using that to generate function name and parameter type information to import.

• If a symbol in symbols.txt cannot be demangled, then we finally fall back to simply importing a label for the address in question.

• TODO: Function types for callback parameters. Bitfields in structs.

[stravant]

Not to be merged yet. Checking with some testers that my instructions work.

[JoshSanch]

I'll have some time to test this tomorrow, but the documentation and structure for this change is looking good. Glad to see some tooling contributions :)

[stravant]

Thoughts on the ghidra_scripts folder being at the top level in the repo? I feel like it's worth it being toplevel but some repos bury it deeper in a tooling folder.

[JoshSanch]

Thoughts on the ghidra_scripts folder being at the top level in the repo? I feel like it's worth it being toplevel but some repos bury it deeper in a tooling folder.

@stravant I actually do think it should be a top-level folder, but inside of the tools subdir. I want to make sure we're not saturating the top-level directory anymore than we need to. Keeping it top-level inside of /tools will give it high visibility without adding more things to figure out in the top-level dir.

[SquareMan]

I also would prefer this to be in tools rather than a top-level dir.

Besides that I do wonder though if this should really be part of this repo instead of it's own project? Is it tightly coupled to BFBB in some way?

[JoshSanch]

I also would prefer this to be in tools rather than a top-level dir.

Besides that I do wonder though if this should really be part of this repo instead of it's own project? Is it tightly coupled to BFBB in some way?

In my opinion, it's just a lot easier to use something like this if it's included in the repo. Given that ease of use is critical for project tooling, I think a good solution could be to move this into its own repo, then add it as a submodule to the tooling directory in the BfBB and TSSM repos.