[PATCH] D94154: Unique Internal Linkage Name suffixes must be demangler friendly

Reid Kleckner via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Jan 6 09:37:10 PST 2021


rnk added a comment.

In D94154#2481491 <https://reviews.llvm.org/D94154#2481491>, @dblaikie wrote:

> This is only demangler friendly if the name is already an itanium mangled name, right? (ie: the name starts with _Z) So it wouldn't work for C code?

I'm pretty sure most demangling tools such as c++filt check for a leading prefix of `_+Z` before demangling, so I don't think there are any concerns for C names. A reasonable demangler would pass them through as is.

> Do you have plans to fix this more generally? (I think to fix it more generally, you might need to move this feature up to clang and have clang mangle the name then add the suffix (at least for itanium mangling - not sure if windows mangling supports arbitrary suffixes like this, @rnk might know) - that way for C functions you can force/enable the mangling as is done for __attribute__((overloadable)) and others (I think __attribute__((enable_if)) also causes mangling of C functions))

That was Sriram's original idea: have the mangler do it. I reviewed the code. Modifying the mangler was fairly complicated, so I suggested doing it in a pass. The original pass also operated by appending a suffix after mangling, it just happened earlier. There isn't a good way to "embed" this uniquification into the Itanium mangling scheme, so far as I am aware. The best way I can think of would be to pretend that internal linkage things are in an anonymous namespace. IIRC there used to be ways to embed something unique into that part of the mangling.

That all said, I don't see any reason to block this decimilization change. It's limited in scope and an obvious improvement.


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

https://reviews.llvm.org/D94154



More information about the llvm-commits mailing list