Correct. The problem is with anonymous/CU-local entities. If two compile units define a class with the same name, then its constructors will have the same mangled name. LLDB will not be able to tell them apart in the clang output without extra information.
This is why I think it would be better to move away from using mangled names as function identifiers (instead of doubling down on it). For regular functions, this is already sort of doable (although not very ergonomic): we can take the existing AsmLabelAttr and – instead of the linkage name – encode any information we need to look up the function into the asm string. If we put some identifier of the module (shared library) and the identifier of the DWARF DIE within that module, then we can get back to the exact same data that we’re using to construct the clang declaration. From that point, we can do anything we want (including using the linkage name to look up the function address).
Of course, this doesn’t help with the constructors, as they don’t have a single linkage name due to the variants. However, that’s the part I like about the new attribute idea. If we are able to attach different metadata (whether it is in string form or otherwise) to each variant, then we can also get back to the DWARF DIE for the constructor and know which constructor variant we are looking for.
From there we still need to look up the correct DWARF definition (so that we know the constructor address and everything), but since this only needs to be done for constructors that are actually called, I think it would be acceptable to use a relatively expensive approach like using the accelerator table to find all constructors with that constructor name, and seeing which one points back to the declaration DIE.
To determine which constructor definition DIE corresponds to which variant, I believe that a new attribute would be the cleanest solution, but I suppose we could get away with parsing the mangled linkage name as well. (The problem with that is that it’s ABI specific, but then again, this whole variant business is ABI specific (MSVC uses an constructor argument for disambiguation), so I don’t think we’ll be able to completely ignore ABI here).