Problem with mangling of primitive types in BFD name mangler

[adinn]

A problem was introduced when the debug info generator introduced support for Java method symbol name mangling on Linux that is compatible with the BFD library used by the Linux debugger and tools, gdb, perf and valgrind. The problem occurs in the mangling of methods with boolean, byte or char arguments e.g.

void java.util.Arrays::fill(byte[]*, int, int, byte)
java.lang.String[]* java.lang.String::split(java.lang.String*, int, boolean)

The mangling algorithm encodes primitive argument types using the single letter encoding employed by gcc for the equivalent integral or floating types e.g. int -> i, float -> f etc. This is fine for most primitive types but does not work for boolean, byte or char. The above methods are mangled, respectively, as

_ZN16java.util.Arrays4fillEJvP6byte[]iib
_ZN16java.lang.String5splitEJP18java.lang.String[]PS_ic

which then demangle as follows

$ c++filt _ZN16java.util.Arrays4fillEJvP6byte[]iic
void java.util.Arrays::fill(byte[]*, int, int, char)
$ c++filt _ZN16java.lang.String5splitEJP18java.lang.String[]PS_ib
java.lang.String[]* java.lang.String::split(java.lang.String*, int, bool)

The token c at the end of the first mangled name identifies a signed 8 bit parameter but the print name for that C++ type in the demangled output is char which, in the context of a Java name, is very confusing.

Likewise the token b at the end of the second identifies a boolean parameter but the C++ print name for that type in the demangled output is bool rather than the expected Java name boolean.

The token t used to denote an unsigned 16 bit parameter decodes to the token unsigned short rather than the desired char.

The mangler should be updated so that the encoded names for primitive types decode to the correct Java names.

[zakkak]

when the debug info generator introduced support for Java method symbol name mangling on Linux that is compatible with the BFD library used by the Linux debugger and tools, gdb, perf and valgrind

FTR the support was added with #4950

[oubidar-Abderrahim]

Thank you for reporting this, we'll take a look into it shortly
Tracked internally on GR 48875