[PATCH] D144049: [Symbolize][MinGW] Support demangling i386 call-conv-decorated C++ names
Martin Storsjö via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Wed Feb 15 00:15:39 PST 2023
mstorsjo added inline comments.
================
Comment at: llvm/lib/DebugInfo/Symbolize/Symbolize.cpp:674
+ if (!IsVectorCall && (Front == '_' || Front == '@'))
+ SymbolName = SymbolName.drop_front();
----------------
I see that the `demanglePE32ExternCFunc` function is restructured a fair bit here, but I kinda fail to see exactly what the intent is - is this a functional change, and in what cases does it change the output/behaviour?
================
Comment at: llvm/lib/DebugInfo/Symbolize/Symbolize.cpp:706
+ // may also be applied on top of the Itanium or Rust name mangling.
+ if (nonMicrosoftDemangle(DemangledCName.c_str(), Result))
+ return Result;
----------------
This part of the change makes sense!
I'm a bit undecided about whether the current flow in the function is the best/ideal/most correct one etc, but it probably works just right for all practical cases.
(For macho/darwin, where is the leading underscore stripped out?)
================
Comment at: llvm/test/DebugInfo/symbolize-demangling-mingw32.s:21
+ .endef
+baz:
+ nop
----------------
Hmm, both this symbol and `g` above, aren't technically valid manglings on i386 at all (although they can be considered reasonable internal symbols anyway, where tools/users could use any names they want).
Would it be useful to add a test for a plain `__cdecl` function with C mangling, i.e. just a plain underscore prefix?
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D144049/new/
https://reviews.llvm.org/D144049
More information about the llvm-commits
mailing list