[all-commits] [llvm/llvm-project] 0e4c7f: [DebugInfo] (Always) include the dwo name in the h...

[Pavel Labath via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 0e4c7fabd3587c7d95fa4733e4a9001a0bae737f
      https://github.com/llvm/llvm-project/commit/0e4c7fabd3587c7d95fa4733e4a9001a0bae737f
  Author: Pavel Labath <pavel at labath.sk>
  Date:   2024-08-05 (Mon, 05 Aug 2024)

  Changed paths:
    M llvm/lib/CodeGen/AsmPrinter/DwarfDebug.cpp
    M llvm/test/CodeGen/X86/dwarf-headers.ll
    M llvm/test/DebugInfo/COFF/fission-cu.ll
    M llvm/test/DebugInfo/COFF/fission-sections.ll
    M llvm/test/DebugInfo/WebAssembly/dwarf-headers.ll
    M llvm/test/DebugInfo/WebAssembly/fission-cu.ll
    M llvm/test/DebugInfo/X86/convert-debugloc.ll
    M llvm/test/DebugInfo/X86/convert-loclist.ll
    M llvm/test/DebugInfo/X86/fission-cu.ll
    M llvm/test/DebugInfo/X86/fission-hash-local.ll
    M llvm/test/DebugInfo/X86/fission-hash.ll
    A llvm/test/DebugInfo/X86/split-dwarf-dwo-hash.ll
    R llvm/test/DebugInfo/X86/split-dwarf-multiple-cu-hash.ll
    M llvm/test/DebugInfo/X86/sret.ll
    M llvm/test/MC/WebAssembly/dwarfdump.ll

  Log Message:
  -----------
  [DebugInfo] (Always) include the dwo name in the hash (#100375)

Since ce0c205813c74b4225180ac8a6e40fd52ea88229, we are doing that if a
single (LTO) compilation contains more than one compile unit, but the
same thing can happen if the non-lto and single-cu lto compilations,
typically when the CU ends up (nearly) empty. In my case, this happened
when LTO emptied two compile units.

Note that the source file name is already a part of the hash, so this
can only happen when a single file is compiled and linked twice into the
same application (most likely with different preprocessor defintiions).
While not exactly common, this pattern is used by some C code to
implement "templates".

The 2017 patch already hinted at the possibility of doing this
unconditionally, and this patch implements that. While the DWARF spec
hints at the option of using the type signature hashing algorithm for
the DWO_id purposes, AFAICT it does not actually require it, so I
believe this change is still conforming.

The relevant section of the spec is in Section 3.1.2 "Skeleton
Compilation Unit Entries" (in non-normative text):

```
The means of determining a compilation unit ID does not need to be
similar or related to the means of determining a type unit signature.
However, it should be suitable for detecting file version skew or other
kinds of mismatched files and for looking up a full split unit in a
DWARF package file (see Section 7.3.5 on page 190).
```



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications