[llvm] [DWARFLinker] Patch DW_AT_LLVM_stmt_sequence in the parallel linker (PR #195388)

[via llvm-commits]

================
@@ -514,8 +514,34 @@ size_t DIEAttributeCloner::cloneScalarAttr(
   } else if (AttrSpec.Attr == dwarf::DW_AT_declaration && Value)
     AttrInfo.IsDeclaration = true;
 
-  return Generator.addScalarAttribute(AttrSpec.Attr, ResultingForm, Value)
-      .second;
+  auto Result =
+      Generator.addScalarAttribute(AttrSpec.Attr, ResultingForm, Value);
+  // Record DW_AT_LLVM_stmt_sequence so the attribute value can be
+  // rewritten with the correct .debug_line offset after the line table
+  // for this CU has been emitted. We also register a DebugOffsetPatch so
+  // that the final-section offset of .debug_line gets added when the
+  // section is placed in the combined output. The assert encodes
+  // dsymutil's placement policy: subprograms (which carry
+  // DW_AT_LLVM_stmt_sequence) are placed in compile units, not type
+  // units, so this attribute should never appear on a type-unit DIE.
+  if (AttrSpec.Attr == dwarf::DW_AT_LLVM_stmt_sequence) {
+    assert(OutUnit.isCompileUnit() &&
----------------
alx32 wrote:

Could a module-scope subprogram end up routed to a type unit via [`DependencyTracker.cpp:158`](https://github.com/llvm/llvm-project/blob/8186fd07edcf/llvm/lib/DWARFLinker/Parallel/DependencyTracker.cpp#L158) and trip this? Wonder if we should bail early like [`cloneBlockAttr`](https://github.com/llvm/llvm-project/blob/8186fd07edcf/llvm/lib/DWARFLinker/Parallel/DIEAttributeCloner.cpp#L551) does.

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