Embedded Memory Explorer Name Demangling Fails

[Dan712]

Embedded Memory Explorer fails to Demangle some template names.  I believe this may have to do with providing a class literal as a template type(C++20).  arm-none-eabi-c++filt.exe in the GCC 14.2.1 toolchain properly decodes the following example Embedded Memory Explorer fails on:
_ZN3utl9SingletonIN3tsk18StaticFreeRTOSTaskIN9KeypadMCU11DevCtlrTaskELNS1_7Stack_tE512ELb0EEEXtlNS_13StringLiteralILj5EEEtlA5_cLc46ELc98ELc115ELc115EEEELh0EXtlNS_23StringLiteralUninferredILj100EEEtlA100_cLc118ELc105ELc114ELc116ELc117ELc97ELc108ELc32ELc118ELc111ELc105ELc100ELc32ELc75ELc101ELc121ELc112ELc97ELc100ELc77ELc67ELc85ELc58ELc58ELc75ELc101ELc121ELc112ELc97ELc100ELc66ELc111ELc111ELc116ELc84ELc97ELc115ELc107ELc58ELc58ELc112ELc111ELc115ELc116ELc66ELc111ELc111ELc116ELc73ELc110ELc105ELc116ELc40ELc41EEEEEnwEj

as

utl::Singleton<tsk::StaticFreeRTOSTask<KeypadMCU::DevCtlrTask, (tsk::Stack_t)512, false>, utl::StringLiteral<5u>{char [5]{(char)46, (char)98, (char)115, (char)115}}, (unsigned char)0, utl::StringLiteralUninferred<100u>{char [100]{(char)118, (char)105, (char)114, (char)116, (char)117, (char)97, (char)108, (char)32, (char)118, (char)111, (char)105, (char)100, (char)32, (char)75, (char)101, (char)121, (char)112, (char)97, (char)100, (char)77, (char)67, (char)85, (char)58, (char)58, (char)75, (char)101, (char)121, (char)112, (char)97, (char)100, (char)66, (char)111, (char)111, (char)116, (char)84, (char)97, (char)115, (char)107, (char)58, (char)58, (char)112, (char)111, (char)115, (char)116, (char)66, (char)111, (char)111, (char)116, (char)73, (char)110, (char)105, (char)116, (char)40, (char)41}}>::operator new(unsigned int)

Could Sysprog either fix this or provide a way to plugin custom demanglers?   A plugin method would be welcome as then the char arrays could be displayed as strings.

 

[support]

Hi,

No problem, the demangler is already a separate DLL with a very simple interface (demangle.dll/demangle64.dll).

#include <cxxabi.h>
#include <stdlib.h>

extern "C" char *__declspec(dllexport) DemangleCXXName2(const char *pName)
{
int status = -1;
return abi::__cxa_demangle(pName, 0, 0, &status);
}

extern "C" void __declspec(dllexport) FreeDemangledCXXName(char *pName)
{
free(pName);
}

You can build with MinGW using the following command line:

g++.exe demangle.cpp -o demangle.dll -shared -static-libgcc -static-libstdc++

We will update the version shipped with VisualGDB based on the latest MinGW toolchain in the final v6.1 release.

[Dan712]

Thanks, recompiling that code fixed a bunch of the failures (after I remembered to pass -static-libgcc -static-libstdc++ to the linker as well).  A couple did remain though, possibly because I was using the Sysprogs MinGW toolchains which are a couple gcc versions behind the arm-eabi gcc version(although binutil c++filt worked fine on both)

[support]

OK, we have rebuilt the demangler DLL based on GCC 15.2, and also updated our MinGW toolchains based on that version.

Feel free to try this build: VisualGDB-6.1.101.5494.msi

[Dan712]

Thanks for the updated version.   Unfortunately this doesn’t seem to fix the remaining bugs.  On reinspection the remaining failures are inherited constructors from using declarations.  Other methods and data members demangle properly.

[support]

No problem. Could you please check whether it works with the c++filt.exe executable from our latest MinGW toolchain?

If not, does it work with any other c++filt version?

[Dan712]

I’ve checked with both MinGW and the toolchain I compiled it on and both c++filt fail.  I may have gone too far with template hacks.

For reference the mangled name:

_ZN3utl9SingletonIN3tsk18StaticFreeRTOSTaskI14UtilMcuLtiTaskLNS1_7Stack_tE1536ELb0EEEXtlNS_13StringLiteralILj5EEEtlA5_cLc46ELc98ELc115ELc115EEEELh0EXtlNS_23StringLiteralUninferredILj100EEEtlA100_cLc85ELc116ELc105ELc108ELc77ELc99ELc117ELc76ELc116ELc105ELc67ELc111ELc110ELc102ELc105ELc103ELc58ELc58ELc85ELc116ELc105ELc108ELc77ELc99ELc117ELc76ELc116ELc105ELc67ELc111ELc110ELc102ELc105ELc103ELc40ELc104ELc100ELc58ELc58ELc73ELc50ELc99ELc66ELc117ELc115ELc88ELc102ELc101ELc114ELc77ELc101ELc100ELc105ELc117ELc109ELc42ELc44ELc32ELc104ELc100ELc58ELc58ELc73ELc50ELc99ELc66ELc117ELc115ELc88ELc102ELc101ELc114ELc77ELc101ELc100ELc105ELc117ELc109ELc42ELc41EEEEECI2S5_IJRN2hc6INA231ESG_SG_SG_SG_SG_RNSE_7BQ25790ESI_EEEPKcNS1_10Priority_tEDpOT_

[Dan712]

This now seems outside of VisualGDB scope, thanks for the help.

[support]

No problem. In our experience the GNU demangler is a few GCC releases behind the GCC itself. So, there’s a good chance that it will work better with GCC 16.0 or 17.0. You can try checking c++filt whenever a new GCC release comes out, and if it works better, we can easily rebuild our demangler using the same gcc version.

[Author]

Posts