Shipping programming language specific extensions to a CPU in a Ghidra Extension

[fmagin]

Some Objective-C functions have a weird calling convention where x1 is effectively skipped, which confuses the decompiler and leads to cluttered variables.
I want to define this as a new prototype and ship it in a plugin [^1]. Some existing processors have extra folders like ghidra_11.3.1_PUBLIC/Ghidra/Processors/x86/data/extensions/rust/unix with files like cc.xml, probe_fixup.xml and try_fixup.xml. The first one seems like what I want: A standalone calling convention added for a specifc language. I can't find any references to these files in the source code directly, so it seems like they are automatically loaded via some mechanism.

My question is:
Can I ship calling convention extensions to existing processor architectures (in my case AARCH64) as part of an extension?
If yes, where do I put the files and control for which binaries they are used?

[^1] After dogfooding this enough I'll probably upstream it, but for now I want to see how much this helps in practice, and I want to understand the general mechanism

[ryanmkurtz]

You should be able to put it in the data/ directory of your module, and then access it like Rust does:

ghidra/Ghidra/Features/Base/src/main/java/ghidra/app/plugin/core/analysis/rust/RustUtilities.java

Lines 98 to 126 in 4192e94

	public static int addExtensions(Program program, TaskMonitor monitor, String subPath)
	throws IOException {
	Processor processor = program.getLanguageCompilerSpecPair().getLanguage().getProcessor();
	ResourceFile module = Application.getModuleDataSubDirectory(processor.toString(),
	RustConstants.RUST_EXTENSIONS_PATH + subPath);
	int extensionCount = 0;
	ResourceFile[] files = module.listFiles();
	if (files != null) {
	for (ResourceFile file : files) {
	InputStream stream = file.getInputStream();
	byte[] bytes = stream.readAllBytes();
	String xml = new String(bytes);
	try {
	SpecExtension extension = new SpecExtension(program);
	extension.addReplaceCompilerSpecExtension(xml, monitor);
	extensionCount++;
	}
	catch (SleighException | SAXException | XmlParseException | LockException e) {
	Msg.error(RustUtilities.class,
	"Failed to load Rust cspec extension: " + file.getAbsolutePath(), e);
	}
	}
	}
	return extensionCount;
	}

[fmagin]

Ah, I thought there was some more generic way than just loading the file and just installing it via the SpecificationExtension. The Rust extensions are loaded as part of the loader process, and I can't edit the Mach-O loader from my extension (AFAIK?). I'm currently using an analyzer to add the spec, but this seems inelegant and not what an analyzer is intended for? But I don't have better ideas either

[ryanmkurtz]

The Rust thing is not our ideal solution...I think there might be some things in the works to improve this (or at least some talk). So, I would not be surprised if the model changes at some point in the future.