MSVC always emits minimal CodeView metadata with compiler information, even when debug info is otherwise disabled. Other tools may rely on this metadata being present. For example, linkers use it to determine whether hotpatching is enabled for the object file.
By chance, two things have prevented the autoupgrade path being exercised much so far: * LLParser setting the debug-info mode to "old" on seeing intrinsics, * The test in AutoUpgrade.cpp wanting to upgrade into a "new" debug-info block. In practice, this appears to mean this code path hasn't seen the various invalid inputs that can come its way. This commit does a number of things: * Tolerates the various illegal inputs that can be written with debug-intrinsics, and that must be tolerated until the Verifier runs, * Printing illegal/null DbgRecord fields must succeed, * Verifier errors need to localise the function/block where the error is, * Tests that now see debug records will print debug-record errors, Plus a few new tests for other intrinsic-to-debug-record failures modes I found. There are also two edge cases: * Some of the unit tests switch back and forth between intrinsic and record modes at will; I've deleted coverage and some assertions to tolerate this as intrinsic support is now Gone (TM), * In sroa-extract-bits.ll, the order of debug records flips. This is because the autoupgrader upgrades in the opposite order to the basic block conversion routines... which doesn't change the record order, but _does_ change the use list order in Metadata! This should (TM) have no consequence to the correctness of LLVM, but will change the order of various records and the order of DWARF record output too. I tried to reduce this patch to a smaller collection of changes, but they're all intertwined, sorry.
Since https://reviews.llvm.org/D144004, DISubprogram's retainedNodes field is used to track DIImportedEntities, in addition to local variables and labels. However, the corresponding update for DebugInfoFinder, to make it visit DISubprogram's retainedNodes, was missing. This is the fix for it. This change is separated from https://github.com/llvm/llvm-project/pull/119001 to simplify it.
Missing semicolon to make XFAIL a comment
See older commit 8037481cb2d729ae3d782c3fed930f69d740fa23.
Currently, each variant in the variant part of a structure type can only
contain a single member. This was sufficient for Rust, where each
variant is represented as its own type.
However, this isn't really enough for Ada, where a variant can have
multiple members.
This patch adds support for this scenario. This is done by allowing the
use of DW_TAG_variant by DICompositeType, and then changing the DWARF
generator to recognize when a DIDerivedType representing a variant holds
one of these. In this case, the fields from the DW_TAG_variant are
inlined into the variant, like so:
```
<4><7d>: Abbrev Number: 9 (DW_TAG_variant)
<7e> DW_AT_discr_value : 74
<5><7f>: Abbrev Number: 7 (DW_TAG_member)
<80> DW_AT_name : (indirect string, offset: 0x43): field0
<84> DW_AT_type : <0xa7>
<88> DW_AT_alignment : 8
<89> DW_AT_data_member_location: 0
<5><8a>: Abbrev Number: 7 (DW_TAG_member)
<8b> DW_AT_name : (indirect string, offset: 0x4a): field1
<8f> DW_AT_type : <0xa7>
<93> DW_AT_alignment : 8
<94> DW_AT_data_member_location: 8
```
Note that the intermediate DIDerivedType is still needed in this
situation, because that is where the discriminants are stored.
On some platforms (particularly macOS), a `\01` prefix gets added to the name in an `asm` label. This gets stripped when we emit the [`DW_AT_linkage_name`](https://github.com/llvm/llvm-project/blob/2f877c2722e882fe6aaaab44d25b7a49ba0612e1/llvm/lib/CodeGen/AsmPrinter/DwarfUnit.cpp#L531). But we weren't stripping this prefix when inserting the linkage name into accelerator tables. This manifested in an issue where LLDB tried to look up a name in the index by linkage name, but wasn't able to find it because we indexed it with the `\01` unstripped. This patch strips the prefix before indexing.
The new test discriminant-member.ll (see #138953) failed on AIX. It
seems that the string form is different in the DWARF. The log reads:
50: DW_AT_name [DW_FORM_string] ("Discr")
... but the test only looks for DW_FORM_strp. Since the precise form
isn't important here, this patch changes the test to accept any string
form.
---------
Co-authored-by: Hubert Tong <hubert.reinterpretcast@gmail.com>