Add an SDK attribute to DICompileUnit

This is part of PR44213 https://bugs.llvm.org/show_bug.cgi?id=44213

When importing (system) Clang modules, LLDB needs to know which SDK
(e.g., MacOSX, iPhoneSi

Add an SDK attribute to DICompileUnit

This is part of PR44213 https://bugs.llvm.org/show_bug.cgi?id=44213

When importing (system) Clang modules, LLDB needs to know which SDK
(e.g., MacOSX, iPhoneSimulator, ...) they came from. While the sysroot
attribute contains the absolute path to the SDK, this doesn't work
well when the debugger is run on a different machine than the
compiler, and the SDKs are installed in different directories. It thus
makes sense to just store the name of the SDK instead of the absolute
path, so it can be found relative to LLDB.

rdar://problem/51645582

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

show more ...

Reland "[DebugInfo][clang][DWARF5]: Added support for debuginfo generation for defaulted parameters
in C++ templates."

This was reverted in 802b22b5c8c30bebc1695a217478be02653c6b53 due to
missing .b

Reland "[DebugInfo][clang][DWARF5]: Added support for debuginfo generation for defaulted parameters
in C++ templates."

This was reverted in 802b22b5c8c30bebc1695a217478be02653c6b53 due to
missing .bc file and a chromium bot failure.
https://bugs.chromium.org/p/chromium/issues/detail?id=1057559#c1
This revision address both of them.

Summary:
This patch adds support for debuginfo generation for defaulted
parameters in clang and also extends corresponding DebugMetadata/IR to support this feature.

Reviewers: probinson, aprantl, dblaikie

Reviewed By: aprantl, dblaikie

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

show more ...

Revert "[DebugInfo][clang][DWARF5]: Added support for debuginfo generation for defaulted parameters"

The Bitcode/DITemplateParameter-5.0.ll test is failing:

FAIL: LLVM :: Bitcode/DITemplateParamete

Revert "[DebugInfo][clang][DWARF5]: Added support for debuginfo generation for defaulted parameters"

The Bitcode/DITemplateParameter-5.0.ll test is failing:

FAIL: LLVM :: Bitcode/DITemplateParameter-5.0.ll (5894 of 36324)
******************** TEST 'LLVM :: Bitcode/DITemplateParameter-5.0.ll' FAILED ********************
Script:
--
: 'RUN: at line 1'; /usr/local/google/home/thakis/src/llvm-project/out/gn/bin/llvm-dis -o - /usr/local/google/home/thakis/src/llvm-project/llvm/test/Bitcode/DITemplateParameter-5.0.ll.bc | /usr/local/google/home/thakis/src/llvm-project/out/gn/bin/FileCheck /usr/local/google/home/thakis/src/llvm-project/llvm/test/Bitcode/DITemplateParameter-5.0.ll
--
Exit Code: 2

Command Output (stderr):
--

It looks like the Bitcode/DITemplateParameter-5.0.ll.bc file was never checked in.

This reverts commit c2b437d53d40b6dc5603c97f527398f477d9c5f1.

show more ...

[DebugInfo][clang][DWARF5]: Added support for debuginfo generation for defaulted parameters
in C++ templates.

Summary:
This patch adds support for debuginfo generation for defaulted
parameters in cl

[DebugInfo][clang][DWARF5]: Added support for debuginfo generation for defaulted parameters
in C++ templates.

Summary:
This patch adds support for debuginfo generation for defaulted
parameters in clang and also extends corresponding DebugMetadata/IR to support this feature.

Reviewers: probinson, aprantl, dblaikie

Reviewed By: aprantl, dblaikie

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

show more ...

Revert "Remove redundant "std::move"s in return statements"

The build failed with

error: call to deleted constructor of 'llvm::Error'

errors.

This reverts commit 1c2241a7936bf85aa68aef94bd40c3b

Revert "Remove redundant "std::move"s in return statements"

The build failed with

error: call to deleted constructor of 'llvm::Error'

errors.

This reverts commit 1c2241a7936bf85aa68aef94bd40c3ba77d8ddf2.

show more ...

Remove redundant "std::move"s in return statements

Move the sysroot attribute from DIModule to DICompileUnit

[this re-applies c0176916a4824812d25a5a22c4ff7c95857b0cd6
with the correct commit message and phabricator link]

This addresses point 1 of

Move the sysroot attribute from DIModule to DICompileUnit

[this re-applies c0176916a4824812d25a5a22c4ff7c95857b0cd6
with the correct commit message and phabricator link]

This addresses point 1 of PR44213.
https://bugs.llvm.org/show_bug.cgi?id=44213

The DW_AT_LLVM_sysroot attribute is used for Clang module debug info,
to allow LLDB to import a Clang module from source. Currently it is
part of each DW_TAG_module, however, it is the same for all modules in
a compile unit. It is more efficient and less ambiguous to store it
once in the DW_TAG_compile_unit.

This should have no effect on DWARF consumers other than LLDB.

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

show more ...

Revert "Rename DW_AT_LLVM_isysroot to DW_AT_LLVM_sysroot"

This reverts commit 12e479475a896f664fb721f98c2d6805185ac352.

I accidentally landed this patch with the wrong commit message ...

Rename DW_AT_LLVM_isysroot to DW_AT_LLVM_sysroot

This is a purely cosmetic change that is NFC in terms of the binary
output. I bugs me that I called the attribute DW_AT_LLVM_isysroot
since the "i" i

Rename DW_AT_LLVM_isysroot to DW_AT_LLVM_sysroot

This is a purely cosmetic change that is NFC in terms of the binary
output. I bugs me that I called the attribute DW_AT_LLVM_isysroot
since the "i" is an artifact of GCC command line option syntax
(-isysroot is in the category of -i options) and doesn't carry any
useful information otherwise.

This attribute only appears in Clang module debug info.

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

show more ...

[NFC] Fix trivial typos in comments

Reviewed By: jhenderson

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

Patch by Kazuaki Ishizaki.

Revert "DebugInfo: Fix rangesBaseAddress DICompileUnit bitcode serialization/deserialization"

Seeing some curious CFI failures internally - which makes little sense
to me, as I don't think anyone is

Revert "DebugInfo: Fix rangesBaseAddress DICompileUnit bitcode serialization/deserialization"

Seeing some curious CFI failures internally - which makes little sense
to me, as I don't think anyone is using this flag (even us,
internally)... so sounds like a bug in my code somewhere (possibly a
latent one that propagating this flag exposed, not sure). Reverting
while I investigate.

This reverts commit c51b45e32ef7f35c11891f60871aa9c2c04cd991.

show more ...

DebugInfo: Fix rangesBaseAddress DICompileUnit bitcode serialization/deserialization

Follow-up to r346788 review feedback from Adrian Prantl.

MetadataLoader upgradeCUVariables() - silence static analyzer dyn_cast_or_null<> null dereference warning. NFCI.

The static analyzer is warning about a potential null dereference, but we know that t

MetadataLoader upgradeCUVariables() - silence static analyzer dyn_cast_or_null<> null dereference warning. NFCI.

The static analyzer is warning about a potential null dereference, but we know that the source won't be null so just use dyn_cast, which will assert if the value somehow is actually null.

llvm-svn: 373448

show more ...

MetadataLoader lazyLoadOneMetadata - silence static analyzer dyn_cast<MDNode> null dereference warning. NFCI.

The static analyzer is warning about a potential null dereference, but we should be able

MetadataLoader lazyLoadOneMetadata - silence static analyzer dyn_cast<MDNode> null dereference warning. NFCI.

The static analyzer is warning about a potential null dereference, but we should be able to use cast<MDNode> directly and if not assert will fire for us.

llvm-svn: 372966

show more ...

[llvm] Migrate llvm::make_unique to std::make_unique

Now that we've moved to C++14, we no longer need the llvm::make_unique
implementation from STLExtras.h. This patch is a mechanical replacement
of

[llvm] Migrate llvm::make_unique to std::make_unique

Now that we've moved to C++14, we no longer need the llvm::make_unique
implementation from STLExtras.h. This patch is a mechanical replacement
of (hopefully) all the llvm::make_unique instances across the monorepo.

llvm-svn: 369013

show more ...

[BitcodeReader] Use tighter upper bound to validate forward references.

At the moment, bitcode files with invalid forward reference can easily
cause the bitcode reader to run out of memory, by creat

[BitcodeReader] Use tighter upper bound to validate forward references.

At the moment, bitcode files with invalid forward reference can easily
cause the bitcode reader to run out of memory, by creating a forward
reference with a very high index.

We can use the size of the bitcode file as an upper bound, because a
valid bitcode file can never contain more records. This should be
sufficient to fail early in most cases. The only exception is large
files with invalid forward references close to the file size.

There are a couple of clusterfuzz runs that fail with out-of-memory
because of very high forward references and they should be fixed by this
patch.

A concrete example for this is D64507, which causes out-of-memory on
systems with low memory, like the hexagon upstream bots.

Reviewers: t.p.northover, thegameg, jfb, efriedma, hfinkel

Reviewed By: jfb

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

llvm-svn: 366017

show more ...

[Bitcode] Move Bitstream to a separate library

This moves Bitcode/Bitstream*, Bitcode/BitCodes.h to Bitstream/.

This is needed to avoid a circular dependency when using the bitstream
code for parsi

[Bitcode] Move Bitstream to a separate library

This moves Bitcode/Bitstream*, Bitcode/BitCodes.h to Bitstream/.

This is needed to avoid a circular dependency when using the bitstream
code for parsing optimization remarks.

Since Bitcode uses Core for the IR part:

libLLVMRemarks -> Bitcode -> Core

and Core uses libLLVMRemarks to generate remarks (see
IR/RemarkStreamer.cpp):

Core -> libLLVMRemarks

we need to separate the Bitstream and Bitcode part.

For clang-doc, it seems that it doesn't need the whole bitcode layer, so
I updated the CMake to only use the bitstream part.

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

llvm-svn: 365091

show more ...

BitStream reader: propagate errors

The bitstream reader handles errors poorly. This has two effects:

* Bugs in file handling (especially modules) manifest as an "unexpected end of
file" crash

BitStream reader: propagate errors

The bitstream reader handles errors poorly. This has two effects:

* Bugs in file handling (especially modules) manifest as an "unexpected end of
file" crash
* Users of clang as a library end up aborting because the code unconditionally
calls `report_fatal_error`

The bitstream reader should be more resilient and return Expected / Error as
soon as an error is encountered, not way late like it does now. This patch
starts doing so and adopting the error handling where I think it makes sense.
There's plenty more to do: this patch propagates errors to be minimally useful,
and follow-ups will propagate them further and improve diagnostics.

https://bugs.llvm.org/show_bug.cgi?id=42311
<rdar://problem/33159405>

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

llvm-svn: 364464

show more ...

[DebugInfo] Delete TypedDINodeRef

TypedDINodeRef<T> is a redundant wrapper of Metadata * that is actually a T *.

Accordingly, change DI{Node,Scope,Type}Ref uses to DI{Node,Scope,Type} * or their co

[DebugInfo] Delete TypedDINodeRef

TypedDINodeRef<T> is a redundant wrapper of Metadata * that is actually a T *.

Accordingly, change DI{Node,Scope,Type}Ref uses to DI{Node,Scope,Type} * or their const variants.
This allows us to delete many resolve() calls that clutter the code.

Reviewed By: rnk

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

llvm-svn: 360108

show more ...

Avoid cppcheck operator precedence warnings. NFCI.

Prefer ((X & Y) ? A : B) to (X & Y ? A : B)

llvm-svn: 359884

Add LLVM IR debug info support for Fortran COMMON blocks

COMMON blocks are a feature of Fortran that has no direct analog in C languages, but they are similar to data sections in assembly langua

Add LLVM IR debug info support for Fortran COMMON blocks

COMMON blocks are a feature of Fortran that has no direct analog in C languages, but they are similar to data sections in assembly language programming. A COMMON block is a named area of memory that holds a collection of variables. Fortran subprograms may map the COMMON block memory area to their own, possibly distinct, non-empty list of variables. A Fortran COMMON block might look like the following example.

COMMON /ALPHA/ I, J

For this construct, the compiler generates a new scope-like DI construct (!DICommonBlock) into which variables (see I, J above) can be placed. As the common block implies a range of storage with global lifetime, the !DICommonBlock refers to a !DIGlobalVariable. The Fortran variable that comprise the COMMON block are also linked via metadata to offsets within the global variable that stands for the entire common block.

@alpha_ = common global %alphabytes_ zeroinitializer, align 64, !dbg !27, !dbg !30, !dbg !33
!14 = distinct !DISubprogram(…)
!20 = distinct !DICommonBlock(scope: !14, declaration: !25, name: "alpha")
!25 = distinct !DIGlobalVariable(scope: !20, name: "common alpha", type: !24)
!27 = !DIGlobalVariableExpression(var: !25, expr: !DIExpression())
!29 = distinct !DIGlobalVariable(scope: !20, name: "i", file: !3, type: !28)
!30 = !DIGlobalVariableExpression(var: !29, expr: !DIExpression())
!31 = distinct !DIGlobalVariable(scope: !20, name: "j", file: !3, type: !28)
!32 = !DIExpression(DW_OP_plus_uconst, 4)
!33 = !DIGlobalVariableExpression(var: !31, expr: !32)

The DWARF generated for this is as follows.

DW_TAG_common_block:
DW_AT_name: alpha
DW_AT_location: @alpha_+0
DW_TAG_variable:
DW_AT_name: common alpha
DW_AT_type: array of 8 bytes
DW_AT_location: @alpha_+0
DW_TAG_variable:
DW_AT_name: i
DW_AT_type: integer*4
DW_AT_location: @Alpha+0
DW_TAG_variable:
DW_AT_name: j
DW_AT_type: integer*4
DW_AT_location: @Alpha+4

Patch by Eric Schweitz!

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

llvm-svn: 357934

show more ...

[DebugInfoMetadata] Move main subprogram DIFlag into DISPFlags

Moving subprogram specific flags into DISPFlags makes IR code more readable.
In addition, we provide free space in DIFlags for other
'n

[DebugInfoMetadata] Move main subprogram DIFlag into DISPFlags

Moving subprogram specific flags into DISPFlags makes IR code more readable.
In addition, we provide free space in DIFlags for other
'non-subprogram-specific' debug info flags.

Patch by Djordje Todorovic.

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

llvm-svn: 356454

show more ...

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the ne

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.

Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.

llvm-svn: 351636

show more ...

[DebugInfo] IR/Bitcode changes for DISubprogram flags.

Packing the flags into one bitcode word will save effort in
adding new flags in the future.

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

[DebugInfo] IR/Bitcode changes for DISubprogram flags.

Packing the flags into one bitcode word will save effort in
adding new flags in the future.

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

llvm-svn: 347806

show more ...

[DebugInfo] DISubprogram flags get their own flags word. NFC.
This will hold flags specific to subprograms. In the future
we could potentially free up scarce bits in DIFlags by moving
subprogram-spec

[DebugInfo] DISubprogram flags get their own flags word. NFC.
This will hold flags specific to subprograms. In the future
we could potentially free up scarce bits in DIFlags by moving
subprogram-specific flags from there to the new flags word.

This patch does not change IR/bitcode formats, that will be
done in a follow-up.

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

llvm-svn: 347239

show more ...