I'm trying to link a symbol's file with mangled generated ones from the header. (matching ROM located functions to the RAM ones.)
In the .sym I have a function with "PFvv" parameter, normally demangled to -> VOID (fn*)(VOID).
The compiler is instead producing the following output as parameter: PFYvv
Result: the linker doesn't link.
Questions:
What does the Y stands for? Is there a reference doc for ARM mangling?
.sym mangled name:
_ZN10CCasd15lolEP13strPcPFvvEhPvm
compiler generated name:
_ZN10CCasd15lolEP13strPcPFYvvEhPvm
.h definition
class CCasd{
static int lol(in_str*h, char* name, void(*fn)(void), unsigned char p, void *s, unsigned long l);
};
POST-ANSWER CODE:
Here is how you can generate both the PFvv and the PFYvv mangled names:
#ifdef __cplusplus
extern "C" { /* C declarations in C++ */
#endif
class CCASD {
public:
static int lol(in_str*h, char* name, void(*fn)(void), unsigned char p, void *s, unsigned long l);//Will be PFYvv
};
#ifdef __cplusplus
} /* End of C declarations */
#endif
class CCASD {
public:
static int lol(in_str*h, char* name, void(*fn)(void), unsigned char p, void *s, unsigned long l);//Will be PFvv
};
Apparently, the ARM ABI is based on the more common Itanium ABI (with some modifications that are enumerated in the linked document).
So we head over there… and discover that the Y
comes from the <function-type>
production of your "pointer to function" type, with the following explanation:
A "Y" prefix for the bare function type encodes extern "C" in implementations which distinguish between function types with "C" and "C++" language linkage. This affects only type mangling, since extern "C" function objects have unmangled names.
As for whether you have one of those implementations (I mean in general; clearly yours is one of them), this answer is worth a read.