How do you add another compiler to Ghidra

[Wall-AF]

Currently Ghidra has several built-in compiler specific details (like those included in windows_v12_32.gtd etc.). I'd like to create something similar for MSVC4.20. I've discovered that those PE files have a major/minor linker attribute available in the Optional PE Header that would identify the compiler, but I've no clue as to how to go about integrating it!

[lightspot21]

What kind of details are you looking to add? As far as I understand, .gdt files store data type definitions, (usually) made by feeding C headers into Ghidra. Can you clarify the use case?

[Wall-AF]

Once you've created your .gtd file and know the magic linker numbers (that identify the compiler), the next time you import something how does Ghidra recogise your new gtd and compiler?

[lightspot21]

I think the keywords to look for are 'loader' and 'opinion'. Here's what I'd do if I were you:

1. Extend Ghidra's PE loader (see https://github.com/NationalSecurityAgency/ghidra/tree/master/Ghidra/Features/Base/src/main/java/ghidra/app/util/opinion/PeLoader.java and the files around it) with any heuristics that identify the specific compiler version.
2. Tell the loader to attach the proper gdt file during the Apply Data Types step.
3. You should be able to automatically use your custom gdt file on any programs that are detected by the loader to be made with the specific compiler.

(I haven't ever had a need to do this, so take these with adequate amounts of salt. If anyone from the Ghidra team or a more experienced user is willing to correct me, please feel free to do so)

[Wall-AF]

Looks a bit nuanced! Need more advice if poss!

[lightspot21]

I went to dig in the source a bit and apparently I was wrong. Here's what actually happens:

Ghidra decides which gdt to apply based on some information about the loaded program. The Apply Data Archives analyzer located at Ghidra/Features/Base/src/main/java/ghidra/app/plugin/core/analysis/ApplyDataArchiveAnalyzer.java, via its getAutoDTMs() method (which is the one called if autodetection is desired), calls out to Ghidra/Features/Base/src/main/java/ghidra/app/plugin/core/datamgr/util/DataTypeArchiveUtility.java, specifically its getArchiveList() method.

Now, getArchiveList() returns all applicable gdts, and it checks whether a gdt could be a match based on heuristics (e.g. if it's a 64-bit PE file, add windows_vs12_64.gdt to the list of matches). I guess to have Ghidra return your gdt file automatically, you should modify getArchiveList() in order to read off the linker attribute you discovered and based on that, return your own gdt file instead of the default.

[ryanmkurtz]

I think Ghidra will automatically discover your GDT file if it resides in some module's data/ directory. Ultimately though, it will be the job of your Analyzer to apply it. You might find the golang example useful. Here is the starting point:

ghidra/Ghidra/Features/Base/src/main/java/ghidra/app/util/bin/format/golang/rtti/GoRttiMapper.java

Lines 218 to 241 in d8dae6d

	/**
	* Searches for a golang bootstrap gdt file that matches the specified Go version/size/OS.
	* <p>
	* First looks for a gdt with an exact match, then for a gdt with version/size match and
	* "any" OS, and finally, a gdt that matches the version and "any" size and "any" OS.
	*
	* @param goVer version of Go
	* @param ptrSize size of pointers
	* @param osName name of OS
	* @return ResourceFile of matching bootstrap gdt, or null if nothing matches
	*/
	public static ResourceFile findGolangBootstrapGDT(GoVer goVer, int ptrSize, String osName) {
	ResourceFile result = null;
	if (osName != null) {
	result = DataTypeArchiveUtility.findArchiveFile(getGDTFilename(goVer, ptrSize, osName));
	}
	if (result == null) {
	result = DataTypeArchiveUtility.findArchiveFile(getGDTFilename(goVer, ptrSize, "any"));
	}
	if (result == null) {
	result =
	DataTypeArchiveUtility.findArchiveFile(getGDTFilename(goVer, -1 /*any*/, "any"));
	}
	return result;