I added a much enhanced stubs importer to svn under tools/ghidra_scripts
It includes a module for loading stubs*.S and csv files, which I hope to reuse for additional scripts.
I've only tested it with 9.1.
Description:
This script prompts for a platform/sub directory, looks for any of
stubs_entry.S, stubs_entry.err.S, stubs_min.S func_by_address.csv
and prompts for which ones to load.
It then attempts to create labels for the loaded function and variable definitions, and start disassembly on the functions if they aren't already disassembled. By default, it also attempts to copy EOL comments from stubs, and clean up incorrect data definitions related to thumb pointers. This can be controlled with options described below.
Variable definitions require that you have created a memory map with the appropriate address space.
It currently loads but does not do anything with DEF_CONST values
Some behavior can be controlled by an ini format configuration file, which is created automatically in the same directory as the script if not present. The default cfg includes a description of each option, and can be created by just running the script and cancelling.
By default, if multiple different names refer to the same address, the script creates multiple labels. This is convenient since you can jump to any of them, and see in the listing when multiple names refer to the same function.
The create_dupe_names option controls this.
There are also options to handle conflicts where one name refers to multiple addresses, both in the stubs files (generally from the csv, where tasks or eventprocs can appear defined with multiple addresses) and pre-existing labels in the Ghidra program (e.g from previous runs with different stubs)
The default is for stubs conflicts (same name with two different addresses) to be named with a suffix like
_stubs_<address>.
The conflict_stubs option controls this.
For conflicts between the incoming stubs and the existing program, the default is to delete the one in the program, so if you had a stub wrong, running the script again with corrected stubs will update it. The conflict_names option controls this.
By default, comments from stubs files that don't look like auto generated match type or score will be added to the program as pre-comments. Any existing comment of the same type will be overwritten. This can be controlled with the stubs_comments and stubs_comments_type options
The script also tries to fix up an issue I noticed on thumb2 firmware, where the analysis can end up creating data at the second byte of a thumb function if it happens to look like a string, do to interpreting a thumb pointer as a possible data address.
The clean_thumb_data option controls this.
