[clang] [clang][MSVC] Correct mangling of thread-safe static initialization variables. (PR #85300)

Tom Honermann via cfe-commits cfe-commits at lists.llvm.org
Thu Mar 14 13:03:33 PDT 2024


================
@@ -3920,7 +3920,8 @@ void MicrosoftMangleContextImpl::mangleThreadSafeStaticGuardVariable(
   msvc_hashing_ostream MHO(Out);
   MicrosoftCXXNameMangler Mangler(*this, MHO);
 
-  Mangler.getStream() << "?$TSS" << GuardNum << '@';
+  Mangler.getStream() << "?";
+  Mangler.mangleSourceName("$TSS" + llvm::utostr(GuardNum));
----------------
tahonermann wrote:

The inclusion of `$` in the source name is correct here. Without that, names might be incorrectly resolved to the implicit name of the guard variable. The added test checks for this. If `$` were not included in the source name, the mangled name for the guard variable would be:
- `?$TSS0@?1??singleton@ 0     NS@@SAAAU02 at XZ@4HA`
instead of:
- `?$TSS0@?1??singleton@ TSS0@ NS@@SAAAU23 at XZ@4HA`

Some brief searches for `mangleSourceName()` in `MicrosoftMangle.cpp` suggests there are quite a few cases of `@` *not* being included in the name registered as a back reference. These cases appear in the following functions. It is difficult to tell if these are intentional or are issues that should be fixed.
- `mangleObjCProtocol()`
- `mangleObjCLifetime()`
- `mangleObjCKindOfType()`
- `mangleAddressSpaceType()`
- `mangleType(const ComplexType *, ...)`
- `mangleType(const VectorType *, ...)`
- `mangleType(const ObjCObjectType *, ...)`
- `mangleType(const AtomicType *, ...)`
- `mangleType(const PipeType *, ...)`
- `mangleType(const BitIntType *, ...)`

There are also some other cases where it looks like a `$` prefixed name is included in the mangled name without being registered as a back reference. These are more difficult to spot without knowing the mangling scheme well. One such example is the one below. Should `$RT` be registered as a back reference? I didn't try to prove it one way or another.
- `mangleReferenceTemporary()`

https://github.com/llvm/llvm-project/pull/85300


More information about the cfe-commits mailing list