Signature Parsing/Ghidra 10 Update

[jturner900]

I'm wondering if you all could help. Upon upgrading to Ghidra 10, a few things broke in our application (as one would expect). We're obtaining decompiled function information with

ghidra.program.model.listing.Function.getSignature,

and using the following method to read this information:

ghidra.app.util.parser.FunctionSignatureParser.parse.

This worked ok for Ghidra 9.1, but now were hitting the exception ParseException("Can't find function name"). One example of a function the parser has trouble with is

ulong __memcmp_sse4_1(undefined (* param_1),undefined (* param_2),ulong param_3)

What changed that made the parser choke? Is it the parenthesis around the pointer declarations? There are other examples where the G10 version of the parser chokes. Is there a better way to generate/read decompiled function information?

[astrelsky]

What do you intend to do with the function information? If you aren't using it outside of Ghidra there should be no reason to be getting the function signature and re parsing it. That being said it definitely shouldn't fail to parse a signature that it created itself.

[jturner900]

The information is used in our plugin to gather statistics about a function (which can reveal a lot about the executable under study). For instance, if an unknown function requires three arguments, we may be able to classify it/group it with other similar methods, rendering it ripe for machine learning, etc.).

Consider the following function:

int memcmp_sse4(undefined (* param_1),byte param_2,ulong param_3)

To us, it's useful information that the second parameter is a byte. Hence, the need to parse this function and categorize it with any three argument-functions with one of them being a byte. The parser, of course, facilitates this.

My initial approach was to make a quick fix and get rid of the parenthesis around the pointer argument; however, there are other features incompatible with the parse method. My naive guess is that getSignature was given a wider range of output formats, and the parser wasn't updated accordingly; but that's well above my paygrade.

I'm not even really sure getSignature and parse are meant to be used together. Perhaps there's a better pair of methods we don't know about.

[ghidra1]

The signature string does not look like valid C syntax. Why the parens in the param declaration? e.g., undefined (* param_1)
I assume this is a simple pointer declaration, e.g., undefined * param_1, which does parse correctly.
How was this signature built-up from the decompiler?