[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