Instead of this:
```
0x00018cff: DW_TAG_imported_declaration
DW_AT_decl_line (12)
DW_AT_import (0x0000000000018cfb)
```
print:
```
0x00018cff: DW_TAG_imported_declaration
DW_AT_decl_line (12)
DW_AT_import (0x0000000000018cfb "platform")
```
Where `0x0000000000018cfb` in this example could be a `DW_TAG_module`
with `DW_AT_name ("platform")`
We shouldn't be calling `getUnversionedName` unconditionally because
DWARFv6-enabled Clang will emit versioned language names that are
versioned (i.e., `sourceLanguageName`...see new test case). We need to
check `hasVersionedName` and pick the appropriate API based on that.
Otherwise we assert in `getUnversionedName`.
The IR->DWARF pipeline was not properly tested before. This patch adds a
test to generate DWARF for various `DIObjCProperty` constructions.
This caught a couple of bugs:
1. The `DW_AT_APPLE_property_getter` and `DW_AT_APPLE_property_setter`
properties were emitted the wrong way around.
2. The `DW_TAG_member` ivars were not linking back to the property that
they back.
These will be fixed in follow-up patches.
In both verbose and non-verbose mode we will now use the
`llvm::dwarf::LanguageDescription` to turn the version into a human
readable string. In verbose mode we also display the raw version code
(similar to how we display addresses in verbose mode). To make the
version code and prettified easier to distinguish, we print the
prettified name in colour (if available), which is consistent with how
`DW_AT_language` is printed in colour.
Before:
```
0x0000000c: DW_TAG_compile_unit
DW_AT_language_name (DW_LNAME_C)
DW_AT_language_version (201112)
```
After:
```
0x0000000c: DW_TAG_compile_unit
DW_AT_language_name (DW_LNAME_C)
DW_AT_language_version (201112 C11)
```
Depends on:
* https://github.com/llvm/llvm-project/pull/162632
Emit `DW_AT_language_version` (new in DWARFv6) if DICompileUnit has a
`sourceLanguageVersion` field. Omit it if it has the default value of
`0` (since it's the default lower bound of any language without a
version scheme).
Depends on:
* https://github.com/llvm/llvm-project/pull/162621
Now we can start emitting `DW_AT_language_name`, make sure
`DwarfUnit::getSourceLanguage` is equipped to handle this. Otherwise the
new test-case would assert.
This is an attempt to reland
https://github.com/llvm/llvm-project/pull/159104 with the fix for
https://github.com/llvm/llvm-project/issues/160197.
The original patch had the following problem: when an abstract
subprogram DIE is constructed from within
`DwarfDebug::endFunctionImpl()`,
`DwarfDebug::constructAbstractSubprogramScopeDIE()` acknowledges `unit:`
field of DISubprogram. But an abstract subprogram DIE constructed from
`DwarfDebug::beginModule()` was put in the same compile unit to which
global variable referencing the subprogram belonged, regardless of
subprogram's `unit:`.
This is fixed by adding `DwarfDebug::getOrCreateAbstractSubprogramCU()`
used by both`DwarfDebug:: constructAbstractSubprogramScopeDIE()` and
`DwarfCompileUnit::getOrCreateSubprogramDIE()` when abstract subprogram
is queried during the creation of DIEs for globals in
`DwarfDebug::beginModule()`.
The fix and the already-reviewed code from
https://github.com/llvm/llvm-project/pull/159104 are two separate
commits in this PR.
=====
The original commit message follows:
With this change, construction of abstract subprogram DIEs is split in
two stages/functions: creation of DIE (in
DwarfCompileUnit::getOrCreateAbstractSubprogramDIE) and its population
with children (in
DwarfCompileUnit::constructAbstractSubprogramScopeDIE).
With that, abstract subprograms can be created/referenced from
DwarfDebug::beginModule, which should solve the issue with static local
variables DIE creation of inlined functons with optimized-out
definitions. It fixes https://github.com/llvm/llvm-project/issues/29985.
LexicalScopes class now stores mapping from DISubprograms to their
corresponding llvm::Function's. It is supposed to be built before
processing of each function (so, now LexicalScopes class has a method
for "module initialization" alongside the method for "function
initialization"). It is used by DwarfCompileUnit to determine whether a
DISubprogram needs an abstract DIE before DwarfDebug::beginFunction is
invoked.
DwarfCompileUnit::getOrCreateSubprogramDIE method is added, which can
create an abstract or a concrete DIE for a subprogram. It accepts
llvm::Function* argument to determine whether a concrete DIE must be
created.
This is a temporary fix for
https://github.com/llvm/llvm-project/issues/29985. Ideally, it will be
fixed by moving global variables and types emission to
DwarfDebug::endModule (https://reviews.llvm.org/D144007,
https://reviews.llvm.org/D144005).
Some code proposed by Ellis Hoag <ellis.sparky.hoag@gmail.com> in
https://github.com/llvm/llvm-project/pull/90523 was taken for this
commit.
With this change, construction of abstract subprogram DIEs is split in
two stages/functions:
creation of DIE (in DwarfCompileUnit::getOrCreateAbstractSubprogramDIE)
and its population with children (in
DwarfCompileUnit::constructAbstractSubprogramScopeDIE).
With that, abstract subprograms can be created/referenced from
DwarfDebug::beginModule, which should solve the issue with static local
variables DIE creation of inlined functons with optimized-out
definitions. It fixes https://github.com/llvm/llvm-project/issues/29985.
LexicalScopes class now stores mapping from DISubprograms to their
corresponding llvm::Function's. It is supposed to be built before
processing of each function (so, now LexicalScopes class has a method
for "module initialization" alongside the method for "function
initialization"). It is used by DwarfCompileUnit to determine whether a
DISubprogram needs an abstract DIE before DwarfDebug::beginFunction is
invoked.
DwarfCompileUnit::getOrCreateSubprogramDIE method is added, which can
create an abstract or a concrete DIE for a subprogram. It accepts
llvm::Function* argument to determine whether a concrete DIE must be
created.
This is a temporary fix for
https://github.com/llvm/llvm-project/issues/29985. Ideally, it will be
fixed by moving global variables and types emission to
DwarfDebug::endModule (https://reviews.llvm.org/D144007,
https://reviews.llvm.org/D144005).
Some code proposed by Ellis Hoag <ellis.sparky.hoag@gmail.com> in
https://github.com/llvm/llvm-project/pull/90523 was taken for this
commit.
This patch is motivated by
https://github.com/llvm/llvm-project/pull/149827, where we plan on using
mangled names on structor declarations to find the exact structor
definition that LLDB's expression evaluator should call.
So far LLVM expects the declaration and definition linkage names to be
identical (or the declaration to just not have a linkage name). But we
plan on attaching the GCC-style "unified" mangled name to declarations,
which will be different to linkage name on the definition. This patch
relaxes this restriction.
Finish making LLVM's implementation of `DW_LNCT_LLVM_source` conform to
the final accepted version of `DW_LNCT_source` from
https://dwarfstd.org/issues/180201.1.html
This is effectively a continuation of a few commits which have moved in
this direction already, including:
* c9cb4fc761cd7 [DebugInfo] Store optional DIFile::Source as pointer
* 87e22bdd2bd6d Allow for mixing source/no-source DIFiles in one CU
This patch:
* Teaches LLParser that there is a distinction between an empty and an
absent "source:" field on DIFile.
* Makes printing the "source:" field in AsmWriter conditional on it
being present, instead of being conditional on it being non-empty.
* Teaches MC to map an empty-but-present source field to "\n" (which is
ambiguous, making the source strings "" and "\n" indistinguishable, but
that's what the DWARF issue specifies).
Add a test for round-tripping an empty source field through
assembler/bitcode.
Extend the test for the actual DWARF generation so it covers all of the
cases (absent, present-but-empty,
present-and-ambiguously-single-newline, present).
RFC on discourse:
https://discourse.llvm.org/t/rfc-debug-info-for-coroutine-suspension-locations-take-2/86606
With this commit, we add `DILabel` debug infos to the resume points of a
coroutine. Those labels can be used by debugging scripts to figure out
the exact line and column at which a coroutine was suspended by looking
up current `__coro_index` value inside the coroutines frame, and then
searching for the corresponding label inside the coroutine's resume
function.
The DWARF information generated for such a label looks like:
```
0x00000f71: DW_TAG_label
DW_AT_name ("__coro_resume_1")
DW_AT_decl_file ("generator-example.cpp")
DW_AT_decl_line (5)
DW_AT_decl_column (3)
DW_AT_artificial (true)
DW_AT_LLVM_coro_suspend_idx (0x01)
DW_AT_low_pc (0x00000000000019be)
```
The labels can be mapped to their corresponding `__coro_idx` values
either via their naming convention `__coro_resume_<N>` or using the new
`DW_AT_LLVM_coro_suspend_idx` attribute. In gdb, those line numebrs can
be looked up using `info line -function my_coroutine -label
__coro_resume_1`. LLDB unfortunately does not understand DW_TAG_label
debug information, yet.
Given this is an artificial compiler-generated label, I did apply the
DW_AT_artificial tag to it. The DWARFv5 standard only allows that tag on
type and variable definitions, but this is a natural extension and was
also blessed in the RFC on discourse.
Also, this commit adds `DW_AT_decl_column` to labels, not only for
coroutines but also for normal C and C++ labels. While not strictly
necessary, I am doing so now because it would be harder to do so later
without breaking the binary LLVM-IR format
Drive-by fixes: While reading the existing test cases to understand how
to write my own test case, I did a couple of small typo fixes and
comment improvements
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.
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`](2f877c2722/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>
This patch adds a couple of improvements to the LLVM emission of DWARF
variant parts. One of these is desirable for Ada, and the other is
required.
Currently, when emitting a discriminant, LLVM follows the precise letter
of the DWARF standard, which says:
If the variant part has a discriminant, the discriminant is
represented by a separate debugging information entry which is a
child of the variant part entry.
However, for Ada this does not really make sense. In Ada, the
discriminant field exists outside of any variant part, and it makes more
sense to emit it separately rather than redundantly emit the field once
for each variant part.
This extension was arrived at when this was implemented in GCC, and was
accepted for DWARF 6, see:
https://dwarfstd.org/issues/180123.1.html
Here the patch simply lifts this restriction: if the discriminant field
was already emitted, it isn't re-emitted. This approach allows the Ada
compiler to do what it needs without affecting the Rust output.
Second, this patch extends the discriminant to allow multiple values.
This is needed by Ada. Here, I chose to use a ConstantDataArray of pairs
of integers, with each pair representing a range, as Ada also allows
ranges here. This seemed like a reasonably convenient representation.
Reverts llvm/llvm-project#136205
Breaks buildbots, probably something about needing to restrict the test
to running on a specific target or the like - I haven't looked closely.
Co-authored-by: Vladislav Dzhidzhoev <dzhidzhoev@gmail.com>
These date back to when the non-intrinsic format of variable locations
was still being tested and was behind a compile-time flag, so not all
builds / bots would correctly run them. The solution at the time, to get
at least some test coverage, was to have tests opt-in to non-intrinsic
debug-info if it was built into LLVM.
Nowadays, non-intrinsic format is the default and has been on for more
than a year, there's no need for this flag to exist.
(I've downgraded the flag from "try" to explicitly requesting
non-intrinsic format in some places, so that we can deal with tests that
are explicitly about non-intrinsic format in their own commit).
My previous patch to add DISubrangeType (#126772) had a couple of minor
errors. This patch corrects them.
1. When using a DISubrangeType as an array index type, the wrong tag was
written into the DIE.
2. I'd intended for subranges to use bit strides, not byte strides --
but neglected to actually implement this. Ada needs bit strides.
This patch adds a new test that checks both these things.
Finally, this patch adds some documentation for DISubrangeType.
If a variant part has a 128-bit discriminator, then
DwarfUnit::constructTypeDIE will assert. This patch fixes the problem
by allowing any size of integer to be used here. This is largely
accomplished by moving part of DwarfUnit::addConstantValue to a new
method.
Fixes#119655
Include a regular expression in the 'REQUIRES' clause, to run
the test on all matching targets (x86_64 *linux*).
The original patch restricted to test just to 'x86_64-linux'
https://github.com/llvm/llvm-project/pull/116327
Consider the case when the compiler generates a static member. Any
consumer of the debug info generated for that case, would benefit if
that member has the DW_AT_artificial flag.
Fix buildbot failure on: llvm-clang-aarch64-darwin
- Add specific configuration: x86_64-linux
Consider the case when the compiler generates a static member. Any
consumer of the debug info generated for that case, would benefit if
that member has the DW_AT_artificial flag.
Enable specialization on literal constant arguments by default in
Function Specialization.
---------
Co-authored-by: Alexandros Lamprineas <alexandros.lamprineas@arm.com>
Store Swift mangled names in DW_AT_linkage_name. The Swift compiler
emits only the type mangled name in debug information, and LLDB uses
those mangled names as keys to look up size, alignment, fields, etc
from either reflection metadata or Swift modules.
Additionally, emit types linkage names for types into the accelerator
table if they exist and they're different from the display name.
Added .setMIFlag(MachineInstr::FrameSetup) to all BuildMI calls in
HexagonFrameLowering::insertAllocframe. This change ensures that the
test sugared-constants.ll passes upstream by correctly marking
instructions as part of the frame setup.
Same fix was provided for AIX in commit
704da919bafa5b088223f9d77424f24ae754539e.
The issue is unsupported DWARF 5 section with the following assertion:
`Assertion failed: Section && "Cannot switch to a null section!", file:
llvm/lib/MC/MCStreamer.cpp, line: 1266 `
