Add llvm-cxxfilt tool?

[alvinhochun]

This should be LLVM's equivalent to c++filt. Think this tool can be useful in some situations.

[alvinhochun]

I'll just make a note here: Because x86-32 cdecl names has an extra leading underscore, c++filt in MSYS2 MINGW32 has --strip-underscore enabled by default. Better check how llvm-cxxfilt handles this.

[mstorsjo]

I'll just make a note here: Because x86-32 cdecl names has an extra leading underscore, c++filt in MSYS2 MINGW32 has --strip-underscore enabled by default. Better check how llvm-cxxfilt handles this.

Yes - with GNU binutils, all tools default to whatever they were built for as the default target.

For LLVM based tools, the simplest thing is to add a custom wrapper executable - e.g. something like the one we had for dlltool, see e.g. 459e37f03fa37f32e606abb6a53170b0297279c1, which then can set various defaults based on either the explicit tool name prefix, or based on the default target (if run unprefixed). The wrappers are ugly and we've tried to get rid of them though, but they're easy to set up for bootstrapping new things.

The less simple but much neater alternative, is to upstream handling to the llvm tool, to infer such things from a target prefix. But for the unprefixed case, it would have to default to the LLVM default target (or host), and I think that might be a breaking change compared to how the tool works now. https://github.com/llvm/llvm-project/commit/ca56b33daf6781a248750b6d538cef84fdae0d1b is an example of how that was done for llvm-dlltool.

[alvinhochun]

I suppose it is perhaps too late to implement such change upstream to be included in LLVM 16. I guess we may have to go with a wrapper for now or maybe even skip it.

If we do make the change upstream though, just having --strip-underscore seems inadequate. It only handles __cdecl but not the other calling conventions. I think it should probably also be changed to support the name mangling of other calling conventions, which might need to be a new option. (Binutils c++filt does not handle them.) WDYT?

[mstorsjo]

I suppose it is perhaps too late to implement such change upstream to be included in LLVM 16.

Yes, definitely.

I guess we may have to go with a wrapper for now or maybe even skip it.

Yeah, having an exact wrapper probably isn't even that very necessary here - the tool probably seldom is used in scripts or other automated cases, and probably mostly used by a human user. So having only llvm-cxxfilt available instead of [prefix-]c++filt might be a useful step on its own, maybe.

If we do make the change upstream though, just having --strip-underscore seems inadequate. It only handles __cdecl but not the other calling conventions. I think it should probably also be changed to support the name mangling of other calling conventions, which might need to be a new option. (Binutils c++filt does not handle them.) WDYT?

I guess it could be useful to handle all of those manglings too (although I'm not sure if it's strictly necessary either). I think the stdcall/fastcall/vectorcall combinations with C++ mangled symbols is mostly a theoretical curiosity - but technically totally valid. And as the tool itself is framed as "demangle itanium symbol names" then it can be considered somewhat out of scope too (although then handling the plain leading underscore could be considered out of scope too).

But if it can be handled neatly I guess it could make sense to support it - I guess it's more of --unwrap-win-i386-decorations than --strip-underscore - since all those manglings are windows specific. Code wise it's probably not very hard.

[alvinhochun]

C++ member functions in stdcall is probably not too uncommon, considering that's what COM class implementations have to use.

--[no-]unwrap-win-i386-decorations sounds good to me.

[mstorsjo]

C++ member functions in stdcall is probably not too uncommon, considering that's what COM class implementations have to use.

Oh, that's true, good point.

--[no-]unwrap-win-i386-decorations sounds good to me.

I'm not entirely in love with the name, but I'm not sure if I have any better suggestions... Lots of people like to use "win32" to specifically mean windows on i386, but that doesn't really differentiate it from e.g. windows on 32 bit arm - since it's very specifically the i386 mode which has lots of oddities, not the bitness itself.

[alvinhochun]

--[no-]unwrap-win-i386-decorations sounds good to me.

I'm not entirely in love with the name, but I'm not sure if I have any better suggestions... Lots of people like to use "win32" to specifically mean windows on i386, but that doesn't really differentiate it from e.g. windows on 32 bit arm - since it's very specifically the i386 mode which has lots of oddities, not the bitness itself.

I guess "win32" may be fine too? AFAIK x86_64, arm32 and arm64 don't have such decorated names so it's not like we need to disambiguate between them. (Though arm64ec has its new # thing, I doubt mingw-w64 will get any support for it any time soon...)

[mstorsjo]

--[no-]unwrap-win-i386-decorations sounds good to me.

I'm not entirely in love with the name, but I'm not sure if I have any better suggestions... Lots of people like to use "win32" to specifically mean windows on i386, but that doesn't really differentiate it from e.g. windows on 32 bit arm - since it's very specifically the i386 mode which has lots of oddities, not the bitness itself.

I guess "win32" may be fine too? AFAIK x86_64, arm32 and arm64 don't have such decorated names so it's not like we need to disambiguate between them. (Though arm64ec has its new # thing, I doubt mingw-w64 will get any support for it any time soon...)

I guess it could be fine too - it's at least less clunky, even if a bit vague.

[UndeadBee42]

@mstorsjo i came here to say that addition of llvm-cxxfilt would make it possible to use compiler explorer with llvm-mingw

[mstorsjo]

@mstorsjo i came here to say that addition of llvm-cxxfilt would make it possible to use compiler explorer with llvm-mingw

Thanks, that's good information. Would it be enough to have the plain llvm-cxxfilt tool, without the <prefix>-c++filt GNU like frontends?

[UndeadBee42]

@mstorsjo i came here to say that addition of llvm-cxxfilt would make it possible to use compiler explorer with llvm-mingw

Thanks, that's good information. Would it be enough to have the plain llvm-cxxfilt tool, without the <prefix>-c++filt GNU like frontends?

it helped to work around need for cxxfilt by specifying demangler=C:\LLVM\bin\llvm-cxxfilt.exe in config but now i tring to figure out lld: error: unknown argument: -rpath error. i will go and ask in their discord about it.

Simple programs do compile

[UndeadBee42]

compiler-explorer dev helped with config compiler.clang.rpathFlag=-L is temporary work around as far as i am aware. here is c++.local.properties file if somebody needs it

compilers=clang compiler.clang.name=clang compiler.clang.exe=C:\Users\User\Desktop\llvm-mingw-20230905-ucrt-x86_64\bin\x86_64-w64-mingw32uwp-clang++.exe demangler=C:\LLVM\bin\llvm-cxxfilt.exe includePath=C:\Users\User\Desktop\llvm-mingw-20230905-ucrt-x86_64\include compiler.clang.rpathFlag=-L objdumper=C:\Users\User\Desktop\llvm-mingw-20230905-ucrt-x86_64\bin\llvm-objdump.exe

[mstorsjo]

I pushed a10755cbd57f9db3b254b24aa26de080add2748f now, which does add the llvm-cxxtool binary. It doesn't provide the [<triple>-]c++filt binutils style frontends though. The commit message explains the reason, as we've discussed here - we'd need to default to the i686 style behaviour both when called with such a prefix, and for the prefixless case when invoked in a build that defaults to i686.