[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,

[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).
```

show more ...

[DWARF] Add linkagename to hash

Originally encountered with RUST, but also there are cases with distributed LTO
where debug info dwo units contain structurally the same debug information, with
diffe

[DWARF] Add linkagename to hash

Originally encountered with RUST, but also there are cases with distributed LTO
where debug info dwo units contain structurally the same debug information, with
difference in DW_AT_linkage_name. This causes collision on DWO ID.

Differential Revision: https://reviews.llvm.org/D129317

show more ...

[DwarfDebug] Restore code that make comments stay aligned in DwarfDebug::emitDebugLocEntry

Commit 2bddab25dba8d4b0 removed a piece of code from
DwarfDebug::emitDebugLocEntry that according to code c

[DwarfDebug] Restore code that make comments stay aligned in DwarfDebug::emitDebugLocEntry

Commit 2bddab25dba8d4b0 removed a piece of code from
DwarfDebug::emitDebugLocEntry that according to code comments
"Make sure comments stay aligned".

This patch restores that piece of code, together with the addition
of some extra checks in an existing lit test to work as a regression
test. Without this patch we incorrectly get
.byte 159 # 0
instead of
.byte 159 # DW_OP_stack_value

Differential Revision: https://reviews.llvm.org/D117441

show more ...

DebugInfo: Don't hash DIE offsets before they're computed

Instead of hashing DIE offsets, hash DIE references the same as they
would be when used outside of a loclist - that is, deep hash the type o

DebugInfo: Don't hash DIE offsets before they're computed

Instead of hashing DIE offsets, hash DIE references the same as they
would be when used outside of a loclist - that is, deep hash the type on
first use, and hash the numbering on subsequent uses.

This does produce different hashes for different type references, where
it did not before (because we were hashing zero all the time - so it
didn't matter what type was referenced, the hash would be identical).

This also allows us to enforce that the DIE offset (& size) is not
queried before it is used (which came up while investigating another bug
recently).

show more ...

[DebugInfo] retainedTypes should not have subprograms

After D80369, the retainedTypes in CU's should not have any subprograms
so we should not handle that case when emitting debug info.

Differentia

[DebugInfo] retainedTypes should not have subprograms

After D80369, the retainedTypes in CU's should not have any subprograms
so we should not handle that case when emitting debug info.

Differential Revision: https://reviews.llvm.org/D111593

show more ...

[DWARF] Revert sharing subprograms across CUs

This patch is a revert of e08f205f5c2c. In that patch, DW_TAG_subprograms
were permitted to be referenced across CU boundaries, to improve stack
trace c

[DWARF] Revert sharing subprograms across CUs

This patch is a revert of e08f205f5c2c. In that patch, DW_TAG_subprograms
were permitted to be referenced across CU boundaries, to improve stack
trace construction using call site information. Unfortunately, as
documented in PR48790, the way that subprograms are "owned" by dwarf units
is sufficiently complicated that subprograms end up in unexpected units,
invalidating cross-unit references.

There's no obvious way to easily fix this, and several attempts have
failed. Revert this to ensure correct DWARF is always emitted.

Three tests change in addition to the reversion, but they're all very
light alterations.

Differential Revision: https://reviews.llvm.org/D107076

show more ...

Add a DIExpression const-folder to prevent silly expressions.

It's entirely possible (because it actually happened) for a bool
variable to end up with a 256-bit DW_AT_const_value. This came about
w

Add a DIExpression const-folder to prevent silly expressions.

It's entirely possible (because it actually happened) for a bool
variable to end up with a 256-bit DW_AT_const_value. This came about
when a local bool variable was initialized from a bitfield in a
32-byte struct of bitfields, and after inlining and constant
propagation, the variable did have a constant value. The sequence of
optimizations had it carrying "i256" values around, but once the
constant made it into the llvm.dbg.value, no further IR changes could
affect it.

Technically the llvm.dbg.value did have a DIExpression to reduce it
back down to 8 bits, but the compiler is in no way ready to emit an
oversized constant *and* a DWARF expression to manipulate it.
Depending on the circumstances, we had either just the very fat bool
value, or an expression with no starting value.

The sequence of optimizations that led to this state did seem pretty
reasonable, so the solution I came up with was to invent a DWARF
constant expression folder. Currently it only does convert ops, but
there's no reason it couldn't do other ops if that became useful.

This broke three tests that depended on having convert ops survive
into the DWARF, so I added an operator that would abort the folder to
each of those tests.

Differential Revision: https://reviews.llvm.org/D106915

show more ...

Revert "[NFC] remove explicit default value for strboolattr attribute in tests"

This reverts commit bda6e5bee04c75b1f1332b4fd1ac4e8ef6c3c247.

See https://lab.llvm.org/buildbot/#/builders/109/builds

Revert "[NFC] remove explicit default value for strboolattr attribute in tests"

This reverts commit bda6e5bee04c75b1f1332b4fd1ac4e8ef6c3c247.

See https://lab.llvm.org/buildbot/#/builders/109/builds/15424 for instance

show more ...

[NFC] remove explicit default value for strboolattr attribute in tests

Since d6de1e1a71406c75a4ea4d5a2fe84289f07ea3a1, no attributes is quivalent to
setting attribute to false.

This is a preliminar

[NFC] remove explicit default value for strboolattr attribute in tests

Since d6de1e1a71406c75a4ea4d5a2fe84289f07ea3a1, no attributes is quivalent to
setting attribute to false.

This is a preliminary commit for https://reviews.llvm.org/D99080

show more ...

DebugInfo: Add some missing explicit target triples.

Based on D91043 by Luís Marques. Thanks Luís!

Differential Revision: https://reviews.llvm.org/D91043

DWARFv5: Disable DW_OP_convert for configurations that don't yet support it

Testing reveals that lldb and gdb have some problems with supporting
DW_OP_convert - gdb with Split DWARF tries to resolve

DWARFv5: Disable DW_OP_convert for configurations that don't yet support it

Testing reveals that lldb and gdb have some problems with supporting
DW_OP_convert - gdb with Split DWARF tries to resolve the CU-relative
DIE offset relative to the skeleton DIE. lldb tries to treat the offset
as absolute, which judging by the llvm-dsymutil support for
DW_OP_convert, I guess works OK in MachO? (though probably llvm-dsymutil
is producing invalid DWARF by resolving the relative reference to an
absolute one?).

Specifically this disables DW_OP_convert usage in DWARFv5 if:
* Tuning for GDB and using Split DWARF
* Tuning for LLDB and not targeting MachO

show more ...

DebugInfo: Hash DW_OP_convert in loclists when using Split DWARF

Originally committed in: 1ced28cbe75ff81f35ac2c71e941041eb3afcd00
Reverted in: f75301d16d444d8cb6810d679290df744bc79ec7

DebugInfo: Hash DW_OP_convert in loclists when using Split DWARF

Originally committed in: 1ced28cbe75ff81f35ac2c71e941041eb3afcd00
Reverted in: f75301d16d444d8cb6810d679290df744bc79ec7

(reverted due to tests failing on non-linux/x86 targets, tests have since been
generalized and specialized... since Split DWARF isn't supported on non-elf
targets anyway and we have no way to run on "whatever elf target is available"
so they fail on MacOS without an explicit target triple)

This code was incorrectly emitting extra bytes into arbitrary parts of
the object file when it was meant to be hashing them to compute the DWO
ID.

Follow-up patch(es) will refactor this API somewhat to make such bugs
harder to introduce, hopefully.

show more ...

DebugInfo: Fix convert-loclist.ll Split DWARF variant to use a hardcoded triple

Since we don't support Split DWARF emission on non-ELF formats, hardcode
an elfine triple (we don't have a way to ask

DebugInfo: Fix convert-loclist.ll Split DWARF variant to use a hardcoded triple

Since we don't support Split DWARF emission on non-ELF formats, hardcode
an elfine triple (we don't have a way to ask for "any ELF triple" it
seems, so hardcoded will have to do)

show more ...

Recommit: DebugInfo: Check DW_OP_convert in loclists with Split DWARF

Originally committed in: 552a8fe12bd1822f48dda2e9e8728a179f82d356
Reverted in: f75301d16d444d8cb6810d679290df744bc79

Recommit: DebugInfo: Check DW_OP_convert in loclists with Split DWARF

Originally committed in: 552a8fe12bd1822f48dda2e9e8728a179f82d356
Reverted in: f75301d16d444d8cb6810d679290df744bc79ec7

Reverted because it was running llc directly (rather than %llc_dwarf)
which uses COFF files on Windows which LLVM doesn't support all DWARF
features in.

This functionality isn't fully working, but sets up the testing for a
follow-on patch that demonstrates and fixes the brokenness related to
DWO ID hashing this construct.

show more ...

DebugInfo: use a symbolic DIE reference in convert-loclist.ll

Reapply: DebugInfo: Add missing test coverage for DW_OP_convert in loclists

Originally committed in: 5327b917e3bd0b3db352cb5a61eea7409f2d1972
and follow on fix: 4f281f047457ce3f1870a9325347622

Reapply: DebugInfo: Add missing test coverage for DW_OP_convert in loclists

Originally committed in: 5327b917e3bd0b3db352cb5a61eea7409f2d1972
and follow on fix: 4f281f047457ce3f1870a93253476222314f420b

Reverted in: 191a9a78b3f4bdf35a30d3480bd630d787a2fdf6
and: f75301d16d444d8cb6810d679290df744bc79ec7

Reverted because it wasn't portable between the targets it was running
on. Using %llc_dwarf ensures the target triple is always elfine and thus
DWARF compatible.

show more ...

Revert "DebugInfo: Check DW_OP_convert in loclists with Split DWARF"
and follow-ups.

This reverts commit 1ced28cbe75ff81f35ac2c71e941041eb3afcd00.
This reverts commit 4f281f047457ce3f1870a9325347622

Revert "DebugInfo: Check DW_OP_convert in loclists with Split DWARF"
and follow-ups.

This reverts commit 1ced28cbe75ff81f35ac2c71e941041eb3afcd00.
This reverts commit 4f281f047457ce3f1870a93253476222314f420b.
This reverts commit 552a8fe12bd1822f48dda2e9e8728a179f82d356.

The test fails on non-Linux.

show more ...

DebugInfo: Hash DW_OP_convert in loclists when using Split DWARF

This code was incorrectly emitting extra bytes into arbitrary parts of
the object file when it was meant to be hashing them to comput

DebugInfo: Hash DW_OP_convert in loclists when using Split DWARF

This code was incorrectly emitting extra bytes into arbitrary parts of
the object file when it was meant to be hashing them to compute the DWO
ID.

Follow-up patch(es) will refactor this API somewhat to make such bugs
harder to introduce, hopefully.

show more ...

DebugInfo: Fix convert-loclist.ll to handle different target instruction lengths

DebugInfo: Check DW_OP_convert in loclists with Split DWARF

DebugInfo: Add missing test coverage for DW_OP_convert in loclists