[dsymutil] `--linker=parallel` causes self-recurring typedef in DIE for `std::string`

[royitaqi]

TL;DR

When running dsymutil --linker=parallel, the generated dSYM contains a DIE (see below), which is a typedef of itself (the address of the DW_TAG_typedef is identical to that of the DW_AT_type).

0x00004cb1: DW_TAG_typedef
              DW_AT_type	(0x00004cb1 "string")
              DW_AT_name	("string")
              DW_AT_decl_line	(45)
              DW_AT_decl_file	("/Applications/Xcode_26.0.0_17A324_fb.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/v1/__fwd/string.h")

Notes:

• This happens on macOS. Not sure if it happens on other OS.
• This causes LLDB to enter infinite recursion when trying to understand this type. See stack trace. See "Step 2" below.
• dsymutil --verify-dwarf=all doesn't report this issue.
• This issue doesn't happen without --linker=parallel. See "Step 3" below.

Repro steps on macOS

Step 1: Create the following main.cpp:

#include <string>
#include <iostream>

int main() {
  std::string f = "Hello World";
  std::cout << f << std::endl;
}

Step 2: Run dsymutil WITH --linker=parallel to repro the issue:

xcrun clang++ -g -O0 -c main.cpp
xcrun clang++ -g -O0 main.o
~/public_llvm/build/bin/dsymutil --verify-dwarf=all --linker=parallel -o a.out.dSYM a.out
dwarfdump a.out.dSYM --name=string
lldb a.out -o "b main.cpp:6" -o "r" -o "p f"

I see these output: https://gist.github.com/royitaqi/1afb74beccfcd011021e339e1dc76e0d

Observe:

• The DIE contains a "string" which is a typedef of itself.
• The --verify-dwarf=all doesn't catch this issue.
• If you attach an lldb to the above lldb, you will see the above call stack.

(optional) Step 3: Run dsymutil WITHOUT --linker=parallel as a comparison:

xcrun clang++ -g -O0 -c main.cpp
xcrun clang++ -g -O0 main.o
~/public_llvm/build/bin/dsymutil --verify-dwarf=all -o a.out.dSYM a.out
dwarfdump a.out.dSYM --name=string
lldb a.out -o "b main.cpp:6" -o "r" -o "p f"

I see these output: https://gist.github.com/royitaqi/e83bb8b986fef3556f2e268e8c7a6eee

Observe:

• The DIE contains one "string" which is a typedef of another "string", which is the actual std::basic_string.
• The "string" type is understood and is printed correctly by lldb.

--

cc @clayborg

[llvmbot]

@llvm/issue-subscribers-debuginfo

Author: Roy Shi (royitaqi)

# TL;DR

With --linker=parallel, the generated dSYM contains a DIE (see below), which is a typedef of itself (see the address of the DW_TAG_typedef is identical to the address of the DW_AT_type).

0x00004cb1: DW_TAG_typedef
              DW_AT_type	(0x00004cb1 "string")
              DW_AT_name	("string")
              DW_AT_decl_line	(45)
              DW_AT_decl_file	("/Applications/Xcode_26.0.0_17A324_fb.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/v1/__fwd/string.h")

Notes:

• This happens on macOS. Not sure if it happens on other OS.
• This causes LLDB to enter infinite recursion when trying to understand this type. See stack trace. See "Step 2" below.
• This issue doesn't happen without --linker=parallel. See "Step 3" below.

Repro steps

Step 1: Create the following main.cpp:

#include <string>
#include <iostream>

int main() {
  std::string f = "Hello World";
  std::cout << f << std::endl;
}

Step 2: Run dsymutil WITH --linker=parallel to repro the issue (on macOS):

xcrun clang++ -g -O0 -c main.cpp
xcrun clang++ -g -O0 main.o
~/public_llvm/build/bin/dsymutil --verify-dwarf=all --linker=parallel -o a.out.dSYM a.out
dddd a.out.dSYM --name=string
lldb a.out -o "b main.cpp:6" -o "r" -o "p f"

I see these output: https://gist.github.com/royitaqi/1afb74beccfcd011021e339e1dc76e0d

Observe:

• The DIE contains a "string" which is a typedef of itself.
• The --verify-dwarf=all doesn't catch this issue.
• If you attach an lldb to the above lldb, you will see the above call stack.

(optional) Step 3: Run dsymutil WITHOUT --linker=parallel as a comparison:

xcrun clang++ -g -O0 -c main.cpp
xcrun clang++ -g -O0 main.o
~/public_llvm/build/bin/dsymutil --verify-dwarf=all -o a.out.dSYM a.out
dddd a.out.dSYM --name=string
lldb a.out -o "b main.cpp:6" -o "r" -o "p f"

I see these output: https://gist.github.com/royitaqi/e83bb8b986fef3556f2e268e8c7a6eee

Observe:

• The DIE contains one "string" which is a typedef of another "string", which is the actual std::basic_string.
• The "string" type is understood and is printed correctly by lldb.

--

cc @clayborg

[llvmbot]

@llvm/issue-subscribers-lldb

Author: Roy Shi (royitaqi)

# TL;DR

With --linker=parallel, the generated dSYM contains a DIE (see below), which is a typedef of itself (see the address of the DW_TAG_typedef is identical to the address of the DW_AT_type).

0x00004cb1: DW_TAG_typedef
              DW_AT_type	(0x00004cb1 "string")
              DW_AT_name	("string")
              DW_AT_decl_line	(45)
              DW_AT_decl_file	("/Applications/Xcode_26.0.0_17A324_fb.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/v1/__fwd/string.h")

Notes:

• This happens on macOS. Not sure if it happens on other OS.
• This causes LLDB to enter infinite recursion when trying to understand this type. See stack trace. See "Step 2" below.
• This issue doesn't happen without --linker=parallel. See "Step 3" below.

Repro steps

Step 1: Create the following main.cpp:

#include <string>
#include <iostream>

int main() {
  std::string f = "Hello World";
  std::cout << f << std::endl;
}

Step 2: Run dsymutil WITH --linker=parallel to repro the issue (on macOS):

xcrun clang++ -g -O0 -c main.cpp
xcrun clang++ -g -O0 main.o
~/public_llvm/build/bin/dsymutil --verify-dwarf=all --linker=parallel -o a.out.dSYM a.out
dddd a.out.dSYM --name=string
lldb a.out -o "b main.cpp:6" -o "r" -o "p f"

I see these output: https://gist.github.com/royitaqi/1afb74beccfcd011021e339e1dc76e0d

Observe:

• The DIE contains a "string" which is a typedef of itself.
• The --verify-dwarf=all doesn't catch this issue.
• If you attach an lldb to the above lldb, you will see the above call stack.

(optional) Step 3: Run dsymutil WITHOUT --linker=parallel as a comparison:

xcrun clang++ -g -O0 -c main.cpp
xcrun clang++ -g -O0 main.o
~/public_llvm/build/bin/dsymutil --verify-dwarf=all -o a.out.dSYM a.out
dddd a.out.dSYM --name=string
lldb a.out -o "b main.cpp:6" -o "r" -o "p f"

I see these output: https://gist.github.com/royitaqi/e83bb8b986fef3556f2e268e8c7a6eee

Observe:

• The DIE contains one "string" which is a typedef of another "string", which is the actual std::basic_string.
• The "string" type is understood and is printed correctly by lldb.

--

cc @clayborg

[Michael137]

yea with lldb tuning we add that indirection typedef for anything that has a preferred_name attribute. Interesting that this happens with the parallel linker only. Can you repro this without std::string, but just by annonating a type with preferred_name?

[royitaqi]

Can you repro this without std::string, but just by annonating a type with preferred_name?

Apologies for my ignorance. How do I do that in a C++ program?

Please kindly LMK if any of the following is what you meant, or give a concrete C++ example:

1. typedef int my_int;
2. using my_int = int;

[Michael137]

Can you repro this without std::string, but just by annonating a type with preferred_name?

Apologies for my ignorance. How do I do that in a C++ program?

Please kindly LMK if any of the following is what you meant, or give a concrete C++ example:

1. `typedef int my_int;`

2. `using my_int = int;`

I meant the [[clang::preferred_name]] attribute

In libc++, std::basic_string is annotated with this attribute:

llvm-project/libcxx/include/__fwd/string.h

Lines 81 to 102 in 6a0e5b2

	template <class _CharT, class _Traits, class _Allocator>
	class _LIBCPP_PREFERRED_NAME(string)
	#if _LIBCPP_HAS_WIDE_CHARACTERS
	_LIBCPP_PREFERRED_NAME(wstring)
	#endif
	#if _LIBCPP_HAS_CHAR8_T
	_LIBCPP_PREFERRED_NAME(u8string)
	#endif
	_LIBCPP_PREFERRED_NAME(u16string)
	_LIBCPP_PREFERRED_NAME(u32string)
	#if _LIBCPP_STD_VER >= 17
	_LIBCPP_PREFERRED_NAME(pmr::string)
	# if _LIBCPP_HAS_WIDE_CHARACTERS
	_LIBCPP_PREFERRED_NAME(pmr::wstring)
	# endif
	# if _LIBCPP_HAS_CHAR8_T
	_LIBCPP_PREFERRED_NAME(pmr::u8string)
	# endif
	_LIBCPP_PREFERRED_NAME(pmr::u16string)
	_LIBCPP_PREFERRED_NAME(pmr::u32string)
	#endif
	basic_string;

The debug-info behaviour where we generated the typedef indirection is implemented here:

llvm-project/clang/lib/CodeGen/CGDebugInfo.cpp

Lines 3163 to 3165 in 6a0e5b2

	if (CGM.getCodeGenOpts().getDebuggerTuning() == llvm::DebuggerKind::LLDB)
	if (auto *PrefDI = GetPreferredNameType(CXXDecl, DefUnit))
	return {FwdDecl, PrefDI};

The intention was to make sure LLDB displays the type of std::basic_string<...> variables using the preferred name (aka std::string).

If you grep for preferred_name in LLDB you should be able to find some test-cases

[royitaqi]

Thanks for the explanation and the pointers. I appreciate it.

Confirming my understanding of the expected behavior:

• dsymutil should generate such DIE (the indirection typedef) both with and without --linker=parallel.
• lldb should be able to work with such DIE and display the preferred name.

I plan to:

• I have found the test case (thanks again for the pointer). It's here. I will read into it.
• I will try to repro with the main.cpp in the above test.

[JDevlieghere]

FWIW, we never qualified the parallel linker on Darwin. It doesn't support ODR uniquing (I believe there is a mode where it does, but then it's not deterministic, which is a dealbreaker). So from my perspective (as the maintainer) the parallel linker in dsymutil (and here I'm not speaking for llvm-dwarfutil) is still experimental.

[royitaqi]

So from my perspective (as the maintainer) the parallel linker in dsymutil (and here I'm not speaking for llvm-dwarfutil) is still experimental.

@JDevlieghere: Thanks for sharing this context.

Let's consider the classic linker. It seems to me the remaining issues are:

• dsymutil should generate indirection typedef DIE with the classic linker.
• lldb should be able to work with such DIE and display the preferred name.

Is my understanding correct?

[royitaqi]

@Michael137 : BTW, I misunderstood what you said. I thought you meant that the recursive DIE is supposed to happen.

Below is my current understanding:

1. A typedef is supposed to exist for types which has clang::preferred_name. It's the "indirection typedef".
2. The typedef is not supposed to generate recursive DIE in any case.
3. It's interesting that it happens with the parallel linker only. The parallel linker is still experimental.
4. The lldb test doesn't use parallel linker. (verified)
5. The lldb test doesn't generate recursive DIE. (yet to verify) And that's why it has been passing in buildbots.

[Michael137]

@Michael137 : BTW, I misunderstood what you said. I thought you meant that the recursive DIE is supposed to happen.

Below is my current understanding:

1. A typedef is supposed to exist for types which has clang::preferred_name. It's the "indirection typedef".
2. The typedef is not supposed to generate recursive DIE in any case.

That is correct. We should not produce recursive DIE references.

4. It's interesting that it happens with the parallel linker only. The parallel linker is still experimental.

IIRC, it also happens when using -gmodules. That's why we don't generate this indirection in that case. The code I pointed you to, checks for that I think. If you comment that if-guard, one of the Clang debug-info tests will exhibit the same kind of recursive typedef you were seeing and crash. I forget the details about how that happens in the -gmodules case though.

8. The lldb test doesn't generate recursive DIE. (yet to verify) And that's why it has been passing in buildbots.

Correct. Does it deterministically fail with the parallel linker? Could you post a dwarfdump of the relevant DIEs where the recursion happens? Maybe we can figure it out from just the dwarfdump

[royitaqi]

Does it deterministically fail with the parallel linker?

Yes, it's pretty consistent on my end (20 out of 20 times).

Could you post a dwarfdump of the relevant DIEs where the recursion happens? Maybe we can figure it out from just the dwarfdump

Here is my latest repro, using a typedef Foo<int> BarInt:

1. See main.cpp. See dwarfdump of the main.o.
2. See (bad) dwarfdump of the dSYM by parallel linker.
3. As comparison, see (good) dwarfdump of the dSYM by classic linker.

The difference in DIE:

1. Both have a Foo<int> struct.
2. Then, on the good side, it has a first BarInt which is a typedef of the Foo<int>, then a second BarInt which is a typedef of the first BarInt.
3. On the bad side, it as a BarInt which is a typedef of itself. It's unrelated to the Foo<int>. --- It is as if the two BarInt in the above (2.) are merged into one, which happens to use the DW_AT_type of the second BarInt (so it's pointing to the first BarInt, which is now itself after the merge).