[PATCH] D138595: [llvm-cxxfilt] Support Microsoft demangling format

David Blaikie via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Dec 1 20:21:42 PST 2022


dblaikie added a comment.

I think the basic idea would be to maybe leave the existing xxxDemangle functions in place, as wrappers around more verbose functions with more precise error handling. (specifically for itaniumDemangle - it'd probably be good for the underlying function to not support fallback to type demangling, it'll be easier to fail out from there & the itaniumDemangle could rall in again and ask specifically for type demangling (there's at least one caller that's doing this already anyway))

So I guess, for instance, `llvm::itaniumDemangle` calls, say, `llvm::itaniumDemangleWithError` that returns `Expected<char*>` - then `llvm::itaniumDemangle` maps failures to nullptr (well, does the fallback to type name demangling if possible, then fails) as before, but llvm-cxxfilt can inspect the error and check if it's some particular custom Error introduced to communicate unrecognized name. Then fallback to the next one, and so on and so forth.

Does that sound feasible? @jhenderson does that sound reasonable? (got other ideas about how this should all be factored?)

To a comment earlier about duplicating/exposing the `is**Encoding`:

> not sure we want to expose those API's since they don't seem 100% complete.

What did you mean by that?

(I personally like the idea of not having separate is* functions and then do* functions when the do* has to do the same work anyway & could report is/isn't in the process)


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D138595/new/

https://reviews.llvm.org/D138595



More information about the llvm-commits mailing list