[Dan712]

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

[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]

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.

[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)

[Dan712]

That method is causing an error in  openocd\src\target\hla_target_hla_multicore.c line 88

‘ARMV7M_S0’ undeclared

[Author]

Posts