Support for DW_FORM_implicit_const DWARFv5 feature.
When this form is used attribute value goes to .debug_abbrev section (as SLEB).
As this form would break any debug tool which doesn't support DWARFv5
it is guarded by dwarf version check. Attempt to use this form with
dwarf version <= 4 is considered a fatal error.

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


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@291599 91177308-0d34-0410-b5e6-96231b3b80d8

LLVM's use of DW_OP_bit_piece is incorrect and a based on a
misunderstanding of the wording in the DWARF specification. The offset
argument of DW_OP_bit_piece refers to the offset into the location
that is on the top of the DWARF expression stack, and not an offset
into the source variable. This has since also been clarified in the
DWARF specification.

This patch fixes all uses of DW_OP_bit_piece to emit the correct
offset and simplifies the DwarfExpression class to semi-automaticaly
emit empty DW_OP_pieces to adjust the offset of the source variable,
thus simplifying the code using DwarfExpression.

While this is an incompatible bugfix, in practice I don't expect this
to be much of a problem since LLVM's old interpretation and the
correct interpretation of DW_OP_bit_piece differ only when there are
gaps in the fragmented locations of the described variables or if
individual fragments are smaller than a byte. LLDB at least won't
interpret locations with gaps in them because is has no way to present
undefined bits in a variable, and there is a high probability that an
old-form expression will be malformed when interpreted correctly,
because the DW_OP_bit_piece offset will be outside of the location at
the top of the stack.

As a nice side-effect, this patch enables us to use a more efficient
encoding for subregisters: In order to express a sub-register at a
non-zero offset we now use a DW_OP_bit_piece instead of shifting the
value into place manually.

This patch also adds missing test coverage for code paths that weren't
exercised before.

<rdar://problem/29335809>
Differential Revision: https://reviews.llvm.org/D27550

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289266 91177308-0d34-0410-b5e6-96231b3b80d8

so we can stop using DW_OP_bit_piece with the wrong semantics.

The entire back story can be found here:
http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20161114/405934.html

The gist is that in LLVM we've been misinterpreting DW_OP_bit_piece's
offset field to mean the offset into the source variable rather than
the offset into the location at the top the DWARF expression stack. In
order to be able to fix this in a subsequent patch, this patch
introduces a dedicated DW_OP_LLVM_fragment operation with the
semantics that we used to apply to DW_OP_bit_piece, which is what we
actually need while inside of LLVM. This patch is complete with a
bitcode upgrade for expressions using the old format. It does not yet
fix the DWARF backend to use DW_OP_bit_piece correctly.

Implementation note: We discussed several options for implementing
this, including reserving a dedicated field in DIExpression for the
fragment size and offset, but using an...

In r266692, we made it possible to emit linkage names for just inlined
functions, putting the attribute on the abstract origin. Make sure we
don't think the linkage-name was already emitted on a declaration.

Differential Revision: http://reviews.llvm.org/D27320


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@288450 91177308-0d34-0410-b5e6-96231b3b80d8

This change removes the dependency on DwarfDebug that was used for DW_FORM_ref_addr by making a new DIEUnit class in DIE.cpp.

The DIEUnit class represents a compile or type unit and it owns the unit DIE as an instance variable. This allows anyone with a DIE, to get the unit DIE, and then get back to its DIEUnit without adding any new ivars to the DIE class. Why was this needed? The DIE class has an Offset that is always the CU relative DIE offset, not the "offset in debug info section" as was commented in the header file (the comment has been corrected). This is great for performance because most DIE references are compile unit relative and this means most code that accessed the DIE's offset didn't need to make it into a compile unit relative offset because it already was. When we needed to emit a DW_FORM_ref_addr though, we needed to find the absolute offset of the DIE by finding the DIE's compile/type unit. This class did have the absolute debug info/type offset and could be added to the CU relative offset to compute the absolute offset. With this change we can easily get back to a DIE's DIEUnit which will have this needed offset. Prior to this is required having a DwarfDebug and required calling:

DwarfCompileUnit *DwarfDebug::lookupUnit(const DIE *CU) const;
Now we can use the DIEUnit class to do so without needing DwarfDebug. All clients now use DIEUnit objects (the DwarfDebug stack and the DwarfLinker). A follow on patch for the DWARF generator will also take advantage of this.

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



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@288399 91177308-0d34-0410-b5e6-96231b3b80d8

Patch by Tom Tromey! (for use with Rust)

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@288068 91177308-0d34-0410-b5e6-96231b3b80d8

This patch makes AsmPrinter less reliant on DwarfDebug by relying on the DWARF version in the AsmPrinter's MCStreamer's MCContext. This allows us to remove the redundant DWARF version from DwarfDebug. It also lets us change code that used to access the AsmPrinter's DwarfDebug just to get to the DWARF version by changing the DWARF version accessor on AsmPrinter so that it grabs the version from its MCStreamer's MCContext.

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


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@287839 91177308-0d34-0410-b5e6-96231b3b80d8

This implements the DWARF 5 DW_AT_export_symbols feature:
http://dwarfstd.org/ShowIssue.php?issue=141212.1

<rdar://problem/18616046>

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@285959 91177308-0d34-0410-b5e6-96231b3b80d8

DW_TAG_atomic_type was already included in Dwarf.defs and emitted correctly,
however Verifier didn't recognize it as valid.
Thus we introduce the following changes:

  * Make DW_TAG_atomic_type valid tag for IR and DWARF (enabled only with -gdwarf-5)
  * Add it to related docs
  * Add DebugInfo tests

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



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@285624 91177308-0d34-0410-b5e6-96231b3b80d8

Change type of some missed DebugInfo-related alignment variables,
that are still uint64_t, to uint32_t.

Original change introduced in r284482.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@285242 91177308-0d34-0410-b5e6-96231b3b80d8

* Assume that clang passes non-zero alignment value to DIBuilder
only in case when it was forced by C++11 'alignas', C11 '_Alignas'
or compiler attribute '__attribute__((aligned (N)))'.

* Emit DW_AT_alignment if alignment is specified for type/object.

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


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@285189 91177308-0d34-0410-b5e6-96231b3b80d8

The commit broke the builds.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@285183 91177308-0d34-0410-b5e6-96231b3b80d8

* Assume that clang passes non-zero alignment value to DIBuilder
only in case when it was forced by C++11 'alignas', C11 '_Alignas'
or compiler attribute '__attribute__((aligned (N)))'.

* Emit DW_AT_alignment if alignment is specified for type/object.

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


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@285181 91177308-0d34-0410-b5e6-96231b3b80d8

 - Add alignment attribute to DIVariable family
 - Modify bitcode format to match new DIVariable representation
 - Update tests to match these changes (also add bitcode upgrade test)
 - Expect that frontend passes non-zero align value only when it is not default
   (was forcibly aligned by alignas()/_Alignas()/__atribute__(aligned())

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


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@284678 91177308-0d34-0410-b5e6-96231b3b80d8

In futher patches we shall have alignment field added to DIVariable family
and switching from uint64_t to uint32_t will save 4 bytes per variable.

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



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@284482 91177308-0d34-0410-b5e6-96231b3b80d8

Differential revision: https://reviews.llvm.org/D23861


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@279695 91177308-0d34-0410-b5e6-96231b3b80d8

This is used to mark functions with the C++11 [[ noreturn ]] or C11 _Noreturn
attributes.

Patch by Victor Leschuk!

https://reviews.llvm.org/D23167

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@278940 91177308-0d34-0410-b5e6-96231b3b80d8

Added support for:
1. Multi dimension array.
2. Array of structure type, which previously was declared incompletely.
3. Dynamic size array.
4. Array where element type is a typedef, volatile or constant (this should resolve PR28311).

Differential Revision: http://reviews.llvm.org/D21526

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@275167 91177308-0d34-0410-b5e6-96231b3b80d8

There exists no relocation which can describe the address of a
dllimported variable: do not try to describe their location.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@274986 91177308-0d34-0410-b5e6-96231b3b80d8

Summary:
Now DISubroutineType has a 'cc' field which should be a DW_CC_ enum.  If
it is present and non-zero, the backend will emit it as a
DW_AT_calling_convention attribute. On the CodeView side, we translate
it to the appropriate enum for the LF_PROCEDURE record.

I added a new LLVM vendor specific enum to the list of DWARF calling
conventions. DWARF does not appear to attempt to standardize these, so I
assume it's OK to do this until we coordinate with GCC on how to emit
vectorcall convention functions.

Reviewers: dexonsmith, majnemer, aaboud, amccarth

Subscribers: mehdi_amini, llvm-commits

Differential Revision: http://reviews.llvm.org/D21114

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@272197 91177308-0d34-0410-b5e6-96231b3b80d8

These attributes aren't used by other debuggers (& may be confused with
other DWARF extensions) so they just waste space (about 1.5% on .dwo
file size on a random large program I tested).

We could remove the ObjC property ones too, but I figured they were
probably more necessary when trying to understand ObjC (I could be wrong
though) & so any debugger interested in working with ObjC would use
them, perhaps? (also, there are some legacy tests in Clang that test for
them - making it one of those annoying cross-project commits and/or
cleanup to refactor those tests)

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@270613 91177308-0d34-0410-b5e6-96231b3b80d8

We are about to start using DIEDwarfExpression to create global variable
DIEs, which happens before we generate code for functions.

Differential Revision: http://reviews.llvm.org/D20412

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@270257 91177308-0d34-0410-b5e6-96231b3b80d8

instead of having DwarfUnit query the debugger tuning options.

Follow-up commmit to r269827.
Thanks to Paul Robinson for pointing this out!

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@269840 91177308-0d34-0410-b5e6-96231b3b80d8

As discovered in PR27758, GDB does not fully support the DWARF 4 format.
This patch ensures we always emit bitfields in the DWARF 2 when tuning for GDB.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@269827 91177308-0d34-0410-b5e6-96231b3b80d8

The DWARF spec states that a member entry may have either a
DW_AT_data_member_location or a DW_AT_data_bit_offset, but not both.

This fixes a bug found in PR 27758.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@269731 91177308-0d34-0410-b5e6-96231b3b80d8

The DWARF spec clearly states that a bit field member should have either a
DW_AT_byte_size or a DW_AT_bit_size, but not both.
Also the DW_AT_byte_size is redundant with the size of the type of the member.

This fixes a bug found in PR 27758.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@269714 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@268150 91177308-0d34-0410-b5e6-96231b3b80d8

After fixing PR26942 in r267004.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@268054 91177308-0d34-0410-b5e6-96231b3b80d8

The DWARF2 specification of DW_AT_bit_offset is ambiguous for
little-endian machines, but by restoring to the old behavior
we match what debuggers expect and what other popular compilers
generate.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@267896 91177308-0d34-0410-b5e6-96231b3b80d8

The DWARF2 specification of DW_AT_bit_offset was written from the perspective of
a big-endian machine with unclear semantics for other systems.  DWARF4
deprecated DW_AT_bit_offset and introduced a new attribute DW_AT_data_bit_offset
that simply counts the number of bits from the beginning of the containing
entity regardless of endianness.

After this patch LLVM emits DW_AT_bit_offset for DWARF 2 or 3 and
DW_AT_data_bit_offset when DWARF 4 or later is requested.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@267895 91177308-0d34-0410-b5e6-96231b3b80d8

Eliminate DITypeIdentifierMap and make DITypeRef a thin wrapper around
DIType*.  It is no longer legal to refer to a DICompositeType by its
'identifier:', and DIBuilder no longer retains all types with an
'identifier:' automatically.

Aside from the bitcode upgrade, this is mainly removing logic to resolve
an MDString-based reference to an actualy DIType.  The commits leading
up to this have made the implicit type map in DICompileUnit's
'retainedTypes:' field superfluous.

This does not remove DITypeRef, DIScopeRef, DINodeRef, and
DITypeRefArray, or stop using them in DI-related metadata.  Although as
of this commit they aren't serving a useful purpose, there are patchces
under review to reuse them for CodeView support.

The tests in LLVM were updated with deref-typerefs.sh, which is attached
to the thread "[RFC] Lazy-loading of debug info metadata":

  http://lists.llvm.org/pipermail/llvm-dev/2016-April/098318.html

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@267296 91177308-0d34-0410-b5e6-96231b3b80d8

When we suppress linkage names, for a non-inlined subprogram the name
can still be found in the object-file symbol table, because we have
the code address of the subprogram.  This is not necessarily the case
for an inlined subprogram, so we still want to emit the linkage name
in the DWARF.  Put this on the abstract-origin DIE because it's common
to all inlined instances.

Differential Revision: http://reviews.llvm.org/D18706


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@266692 91177308-0d34-0410-b5e6-96231b3b80d8

Revert "Recommitted r263424 "Supporting all entities declared in lexical scope in LLVM debug info." After fixing PR26942 (the fix is included in this commit)."

This reverts commit r264280.

This broke building Chromium for iOS. We'll upload a reproducer to the
PR soon.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@264334 91177308-0d34-0410-b5e6-96231b3b80d8

After fixing PR26942 (the fix is included in this commit).

Differential Revision: http://reviews.llvm.org/D18350


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@264280 91177308-0d34-0410-b5e6-96231b3b80d8

A virtual index of -1u indicates that the subprogram's virtual index is
unrepresentable (for example, when using the relative vtable ABI), so do
not emit a DW_AT_vtable_elem_location attribute for it.

Differential Revision: http://reviews.llvm.org/D18236

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@263765 91177308-0d34-0410-b5e6-96231b3b80d8

Revert "Recommitted r261633 "Supporting all entities declared in lexical scope in LLVM debug info." After fixing PR26715 at r263379."

This reverts commit r263424. Breaks self-host.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@263437 91177308-0d34-0410-b5e6-96231b3b80d8

After fixing PR26715 at r263379.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@263424 91177308-0d34-0410-b5e6-96231b3b80d8

This and the corresponding Clang change caused PR26715.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@261671 91177308-0d34-0410-b5e6-96231b3b80d8

Differential Revision: http://reviews.llvm.org/D15976

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@261633 91177308-0d34-0410-b5e6-96231b3b80d8

Rather than storing type units in a vector and emitting them at the end
of code generation, emit them immediately and destroy them, reclaiming the
memory we were using for their DIEs.

In one benchmark carried out against Chromium's 50 largest (by bitcode
file size) translation units, total peak memory consumption with type units
decreased by median 17%, or by 7% when compared against disabling type units.

Tested using check-{llvm,clang}, the GDB 7.5 test suite (with
'-fdebug-types-section') and by eyeballing llvm-dwarfdump output on those
Chromium translation units with split DWARF both disabled and enabled, and
verifying that the only changes were to addresses and abbreviation ordering.

Differential Revision: http://reviews.llvm.org/D17118

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@260578 91177308-0d34-0410-b5e6-96231b3b80d8