This patch moves `ArraySizeModifier` before `Type` declaration so that it's complete at `ArrayTypeBitfields` declaration. It's also converted to scoped enum along the way.
Do not emit call to llvm.dbg.declare when the variable declaration
is a DecompositionDecl as its instance class is always unnamed.
The emitted debug declare looks like:
call void @llvm.dbg.declare(metadata ..., metadata !xx, metadata ...)
!xx = !DILocalVariable(scope: !..., file: !..., line: ..., type: !...)
This attribute allows user to specify type of the bitfield that will be
emitted to debug info without affecting semantics of the program. Since
it doesn't affect semantics, this attribute can be safely ignored by
other compilers.
This is useful when user is forced to use the same type for all
bitfields in a class to get better
[layout](https://godbolt.org/z/ovWqzqv9x) and
[codegen](https://godbolt.org/z/bdoqvz9e6) from MSVC, because it allows
debuggers to interpret the value of bitfield in the most human-friendly
way (e.g. when value actually comes from an enum). This is driven by my
work on LLDB formatters for Clang. I have two use cases for this:
```cpp
namespace Clang {
class Type {
enum TypeClass { ... };
struct TypeBitfields {
[[clang::preferred_type(clang::Type::TypeClass)]] unsigned TC: 8;
[[clang::preferred_type(bool)]] mutable unsigned FromAST : 1;
};
};
}
```
This patch adds `CC_M68kRTD`, which will be used on function if either
`__attribute__((m68k_rtd))` is presented or `-mrtd` flag is given.
Differential Revision: https://reviews.llvm.org/D149867
D155991 changed the file lookup to do a full string compare on the
filename; however, this added ~0.5% to compile time with -g.
Go back to the previous pointer-based lookup, but capture the main
file's checksum as well as its name to use when creating the extra
DIFile entry. This causes all entries to be consistent and also
avoids computing the checksum twice.
This reverts commit 5956648fc3ba11dd6b0d0f2d1d9b923e7f80f247.
There was a string lifetime issue that is now corrected.
Differential Revision: https://reviews.llvm.org/D156571
D155991 changed the file lookup to do a full string compare on the
filename; however, this added ~0.5% to compile time with -g.
Go back to the previous pointer-based lookup, but capture the main
file's checksum as well as its name to use when creating the extra
DIFile entry. This causes all entries to be consistent and also
avoids computing the checksum twice.
This reverts commit 21e7f73494663814e0296066895dfacdebfac6d4.
I'm unable to find a reason for the memory management issues
that caused the revert, so trying again.
D155991 changed the file lookup to do a full string compare on the
filename; however, this added ~0.5% to compile time with -g.
Go back to the previous pointer-based lookup, but capture the main
file's checksum as well as its name to use when creating the extra
DIFile entry. This causes all entries to be consistent and also
avoids computing the checksum twice.
Differential revision: https://reviews.llvm.org/D156571
In cases where a structured binding declaration is made to a struct with
bitfields:
struct A {
unsigned int x : 16;
unsigned int y : 16;
} g;
auto [a, b] = g; // structured binding declaration
Clang assigns the 'unsigned int' DWARF base type to 'a' and 'b' because
this is their deduced C++ type in the structured binding declaration.
However, their actual type in memory is 'unsigned short' as they have 16
bits allocated for each.
This is a problem for debug information consumers: if the debug
information for 'a' has the 'unsigned int' base type, a debugger will
assume it has 4 bytes, whereas it actually has a length of 2, resulting
in a read (or write) past its length.
This patch mimics GCC's behaviour: in case of structured bindings to
bitfields, the binding declaration's DWARF base type is of the target's
integer type with the same bitwidth as the bitfield.
If no suitable integer type is found in the target, no debug information
is emitted anymore in order to prevent wrong debug output.
Reviewed By: tmatheson
Differential Revision: https://reviews.llvm.org/D157479
Currently we emit `DW_AT_deleted` for `deleted` special-member
functions (i.e., ctors/dtors). However, in C++ one can mark any
member function as deleted. This patch expands the set of member
functions for which we emit `DW_AT_deleted`.
The DWARFv5 spec section 5.7.8 says:
```
<non-normative>
In C++, a member function may be declared as deleted. This prevents the compiler from
generating a default implementation of a special member function such as a constructor
or destructor, and can affect overload resolution when used on other member functions.
</non-normative>
If the member function entry has been declared as deleted, then that entry has a
DW_AT_deleted attribute.
```
Thus this change is conforming.
Differential Revision: https://reviews.llvm.org/D153282
On Apple platforms, we generate .apple_names, .apple_types,
.apple_namespaces and .apple_objc Apple accelerator tables for DWARF 4
and earlier. For DWARF 5 we should generate .debug_names, but instead we
get no accelerator tables at all.
In the backend we are correctly determining that we should be emitting
.debug_names instead of .apple_names. However, when we get to the point
of emitting the section, if the CU debug name table kind is not
"default", the accelerator table emission is skipped.
This patch sets the DebugNameTableKind to Apple in the frontend when
target an Apple target. That way we know that the CU was compiled with
the intent of emitting accelerator tables. For DWARF 4 and earlier, that
means Apple accelerator tables. For DWARF 5 and later, that means .debug
names.
Differential revision: https://reviews.llvm.org/D118754
On Apple platforms, we generate .apple_names, .apple_types,
.apple_namespaces and .apple_objc Apple accelerator tables for DWARF 4
and earlier. For DWARF 5 we should generate .debug_names, but instead we
get no accelerator tables at all.
In the backend we are correctly determining that we should be emitting
.debug_names instead of .apple_names. However, when we get to the point
of emitting the section, if the CU debug name table kind is not
"default", the accelerator table emission is skipped.
This patch sets the DebugNameTableKind to Apple in the frontend when
target an Apple target. That way we know that the CU was compiled with
the intent of emitting accelerator tables. For DWARF 4 and earlier, that
means Apple accelerator tables. For DWARF 5 and later, that means .debug
names.
Differential revision: https://reviews.llvm.org/D118754
This patch uses castAs instead of getAs which will assert if the type doesn't match to resolve dereference issue with nullptr FPT when calling getThisType() in clang::CodeGen::CGDebugInfo::CreateType(clang::MemberPointerType const *, llvm::DIFile *).
Reviewed By: erichkeane
Differential Revision: https://reviews.llvm.org/D151947
After a07b135ce0c0111bd83450b5dc29ef0381cdbc39, we always pass
-coverage-notes-file/-coverage-data-file for driver options
-ftest-coverage/-fprofile-arcs/--coverage. As a bonus, we can make the following
simplification to cc1 options:
* `-ftest-coverage -coverage-notes-file a.gcno` => `-coverage-notes-file a.gcno`
* `-fprofile-arcs -coverage-data-file a.gcda` => `-coverage-data-file a.gcda`
and remove EmitCovNotes/EmitCovArcs.
For
`clang -c -g -fdebug-prefix-map=a/b=y -fdebug-prefix-map=a=x a/b/c.c`,
we apply the longest prefix substitution, but
GCC has always been picking the last applicable option (`a=x`, see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109591).
I feel that GCC's behavior is reasonable given the convention that the last
value wins for the same option.
Before D49466, Clang appeared to apply the shortest prefix substitution,
which likely made the least sense.
Reviewed By: #debug-info, scott.linder
Differential Revision: https://reviews.llvm.org/D148975
This fixes two problems:
1. When crossing compiling for windows on linux, source file path in debug info is concatenated with directory by host native separator ('/'). For windows local build, they are concatenated by '\'. This causes non-determinism bug.
The solution here is to let `LangOptions.UseTargetPathSeparator` to control if we should use host native separator or not.
2. Objectfile path in CodeView also uses host native separator when generated.
It's fixed by changing the path separator in `/Fo` to '\' if the path is not an absolute path when adding the `-object-file-name=` flag.
Reviewed By: hans
Differential Revision: https://reviews.llvm.org/D147256
With this patch, whenever we emit a `DW_AT_type` for some declaration
and the type is a template class with a `clang::PreferredNameAttr`, we
will emit the typedef that the attribute refers to instead. I.e.,
```
0x123 DW_TAG_variable
DW_AT_name "var"
DW_AT_type (0x123 "basic_string<char>")
0x124 DW_TAG_structure_type
DW_AT_name "basic_string<char>"
```
...becomes
```
0x123 DW_TAG_variable
DW_AT_name "var"
DW_AT_type (0x124 "std::string")
0x124 DW_TAG_structure_type
DW_AT_name "basic_string<char>"
0x125 DW_TAG_typedef
DW_AT_name "std::string"
DW_AT_type (0x124 "basic_string<char>")
```
We do this by returning the preferred name typedef `DIType` when
we create a structure definition. In some cases, e.g., with `-gmodules`,
we don't complete the structure definition immediately but do so later
via `completeClassData`, which overwrites the `TypeCache`. In such cases
we don't actually want to rewrite the cache with the preferred name. We
handle this by returning both the definition and the preferred typedef
from `CreateTypeDefinition` and let the callee decide what to do with
it.
Essentially we set up the types as:
```
TypeCache[Record] => DICompositeType
ReplaceMap[Record] => DIDerivedType(baseType: DICompositeType)
```
For now we keep this behind LLDB tuning.
**Testing**
- Added clang unit-test
- `check-llvm`, `check-clang` pass
- Confirmed that this change correctly repoints
`basic_string` references in some of my test programs.
- Will add follow-up LLDB API tests
Differential Revision: https://reviews.llvm.org/D145803
This patch moves the Debug Options to llvm/Frontend so that it can be shared by Flang as well.
Reviewed By: kiranchandramohan, awarzynski
Differential Revision: https://reviews.llvm.org/D142347
Consider the following sturctures when targetting:
struct foo {
int space[4];
char a : 8;
char b : 8;
char x : 8;
char y : 8;
};
struct bar {
int space[4];
char a : 8;
char b : 8;
char : 0;
char x : 8;
char y : 8;
};
Even if both structs have the same layout in memory, they are handled
differenlty by the AMDGPU ABI.
With the following code:
// clang --target=amdgcn-amd-amdhsa -g -O1 example.c -S
char use_foo(struct foo f) { return f.y; }
char use_bar(struct bar b) { return b.y; }
For use_foo, the 'y' field is passed in v4
; v_ashrrev_i32_e32 v0, 24, v4
; s_setpc_b64 s[30:31]
For use_bar, the 'y' field is passed in v5
; v_bfe_i32 v0, v5, 8, 8
; s_setpc_b64 s[30:31]
To make this distinction, we record a single 0-size bitfield for every member that is preceded
by it.
Reviewed By: probinson
Differential Revision: https://reviews.llvm.org/D144870
This patch adds the builtin type __SVCount_t to Clang, which is an opaque
scalable type defined in the SME2 C and C++ Language Extensions.
The type maps to the `target("aarch64.svcount")` LLVM IR type.
Reviewed By: paulwalker-arm
Differential Revision: https://reviews.llvm.org/D136864
Such a type is never going to have a ctor home, and may be used for type
punning or other ways of creating objects.
May be a more generally acceptable solution in some cases compared to
attributing with [[clang::standalone_debug]].
Differential Revision: https://reviews.llvm.org/D144931
The function `CGDebugInfo::EmitFunctionDecl` is supposed to create a
declaration -- never a _definition_ -- of a subprogram. This is made
evident by the fact that the SPFlags never have the "Declaration" bit
set by that function.
However, when `EmitFunctionDecl` calls `DIBuilder::createFunction`, it
still tries to fill the "Declaration" argument by passing it the result
of `getFunctionDeclaration(D)`. This will query an internal cache of
previously created declarations and, for most code paths, we return
nullptr; all is good.
However, as reported in [0], there are pathological cases in which we
attempt to recreate a declaration, so the cache query succeeds,
resulting in a subprogram declaration whose declaration field points to
another declaration. Through a series of RAUWs, the declaration field
ends up pointing to the SP itself. Self-referential MDNodes can't be
`unique`, which causes the verifier to fail (declarations must be
`unique`).
We can argue that the caller should check the cache first, but this is
not a correctness issue (declarations are `unique` anyway). The bug is
that `CGDebugInfo::EmitFunctionDecl` should always pass `nullptr` to the
declaration argument of `DIBuilder::createFunction`, expressing the fact
that declarations don't point to other declarations. AFAICT this is not
something for which any reasonable meaning exists.
This seems a lot like a copy-paste mistake that has survived for ~10
years, since other places in this file have the exact same call almost
token-by-token.
I've tested this by compiling LLVMSupport with and without the patch, O2
and O0, and comparing the dwarfdump of the lib. The dumps are identical
modulo the attributes decl_file/producer/comp_dir.
[0]: https://github.com/llvm/llvm-project/issues/59241
Differential Revision: https://reviews.llvm.org/D143921
This patch introduces a new type __externref_t that denotes a WebAssembly opaque
reference type. It also implements builtin __builtin_wasm_ref_null_extern(),
that returns a null value of __externref_t. This lays the ground work
for further builtins and reference types.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D122215
The commit was reverted due to a regression in debug information of an
optimized code test in lldb. This has since been addressed by:
1. rGf753e5be8239: [LiveDebugValues] Allow EntryValue with OP_deref
expressions
2. rG055f2f04e658: [mem2reg][debuginfo] Handle op_deref when converting
dbg.declare
Differential Revision: https://reviews.llvm.org/D141381
This patch introduces a new type __externref_t that denotes a WebAssembly opaque
reference type. It also implements builtin __builtin_wasm_ref_null_extern(),
that returns a null value of __externref_t. This lays the ground work
for further builtins and reference types.
Differential Revision: https://reviews.llvm.org/D122215
Since `ClassTemplateSpecializationDecl`s now set the
`TemplateArgument::IsDefaulted` bit, there's no need
to derive it here.
Differential Revision: https://reviews.llvm.org/D142333
**Summary**
This patch customizes the `CGDebugInfo` printing policy to stop canonicalizing
the template arugment list in `DW_AT_name` for alias templates. The motivation for
this is that we want to be able to use the `TypePrinter`s support for
omitting defaulted template arguments when emitting `DW_AT_name`.
For reference, GCC currently completely omits the template arguments
when emitting alias template DIEs.
**Testing**
* Added unit-test
Differential Revision: https://reviews.llvm.org/D142268
With codegen prior to this patch, truly indirect arguments -- i.e.
those that are not `byval` -- can have their debug information lost even
at O0. Because indirect arguments are passed by pointer, and this
pointer is likely placed in a register as per the function call ABI,
debug information is lost as soon as the register gets clobbered.
This patch solves the issue by storing the address of the parameter on
the stack, using a similar strategy employed when C++ references are
passed. In other words, this patch changes codegen from:
```
define @foo(ptr %arg) {
call void @llvm.dbg.declare(%arg, [...], metadata !DIExpression())
```
To:
```
define @foo(ptr %arg) {
%ptr_storage = alloca ptr
store ptr %arg, ptr %ptr_storage
call void @llvm.dbg.declare(%ptr_storage, [...], metadata !DIExpression(DW_OP_deref))
```
Some common cases where this may happen with C or C++ function calls:
1. "Big enough" trivial structures passed by value under the ARM ABI.
2. Structures that are non-trivial for the purposes of call (as per
the Itanium ABI) when passed by value.
A few tests were matching the wrong alloca (matching against the new
alloca, instead of the old one), so they were updated to either match
both allocas or include a `,` right after the alloca type, to prevent
matching against a pointer type.
Differential Revision: https://reviews.llvm.org/D141381
Generate DILocalVariable entries for parameters of extern functions,
the "annotations" field of DILocalVariable is used to link
"btf_decl_tag" annotation with the parameter.
Do this only for BPF backend as there are no other users for this
information. Final DWARF is valid as "Appendix A" is very much lax in
what is allowed as attributes for "DW_TAG_formal_parameter":
DWARF does not in general require that a given debugging information
entry contain a particular attribute or set of attributes. Instead,
a DWARF producer is free to generate any, all, or none of the
attributes ... other attributes ... may also appear in a given
debugging information entry.
DWARF Debugging Information Format Version 5,
Appendix A: Attributes by Tag Value (Informative)
Page 251, Line 3.
Differential Revision: https://reviews.llvm.org/D140970
The needed tweaks are mostly trivial, the one nasty bit is Clang's usage
of OptionalStorage. To keep this working old Optional stays around as
clang::CustomizableOptional, with the default Storage removed.
Optional<File/DirectoryEntryRef> is replaced with a typedef.
I tested this with GCC 7.5, the oldest supported GCC I had around.
Differential Revision: https://reviews.llvm.org/D140332
This reverts commit 8f0df9f3bbc6d7f3d5cbfd955c5ee4404c53a75d.
The Optional*RefDegradesTo*EntryPtr types want to keep the same size as
the underlying type, which std::optional doesn't guarantee. For use with
llvm::Optional, they define their own storage class, and there is no way
to do that in std::optional.
On top of that, that commit broke builds with older GCCs, where
std::optional was not trivially copyable (static_assert in the clang
sources was failing).
After this patch, in the following snippet:
```
template <typename T> Foo {};
template <template <typename T> class CT = Foo> Bar {};
Bar<> b;
```
The debug-info entry for the `CT` template parameter will have
a `DW_AT_default_value (true)` attached to it.
Differential Revision: https://reviews.llvm.org/D139989
DWARFv5 added support for labelling template parameters with
DW_AT_default_value to indicate whether the particular instantiation
defaulted parameter. The current implementation only supports a limited
set of possible cases. Namely for non-value-dependent integral template
parameters and simple type template parameters.
Useful cases that don't work are:
1. Type template parameters with defaults that are
themselves templates. E.g.,
```
template<typename T1, typename T2 = Foo<T1>> class C1;
template<typename T = Foo<int>> class C2;
etc.
```
2. Template template parameters
`clang::isSubstitutedDefaultArgument` already implement the required logic
to determine whether a template argument is defaulted. This patch re-uses
this logic for DWARF CodeGen.
Differential Revision: https://reviews.llvm.org/D139988
**Summary**
Starting with DWARFv5, DW_AT_default_value can be used to indicate
that a template argument has a default value. With this patch Clang
will attach the attribute to the debug metadata regardless of version.
In a follow-up patch we will change llvm to emit this attribute in
earlier versions of DWARF, unless compiling with -gstrict-dwarf.
**Details**
* Previously the DwarfVersion check in CGDebugInfo was inconsistent:
For non-type template arguments we attached the attribute to the debug
metadata in DWARFv5 only. Whereas for type template arguments we didn't
have such a version restriction. With this patch we attach the attribute
regardless of DWARF version (and instead offload the check to the AsmPrinter
in a future patch).
This may be a breaking change for consumers if they're trying to detect
if code is C or C++, since it'll start using new codes that they may not
be ready to recognize, in which case they may fall back to non-C
handling.
This caused regressions due to PS4 having a different default for C
language version than other targets. Those tests were adapted to be
relaxed about which C version is used.
This reapplies commit 3c312e48f325c1b1ee11404ee6cfa08ee00037b0
Which was reverted by commit 6ab6085c77ef9bcdabf842342f63fba4291791a4.
Differential Revision: https://reviews.llvm.org/D138597
Some buildbots are failing in Clang and LLDB tests. (I guess the LLDB
failure is due to the explicit C language tests in DwarfUnit.cpp that
need to be updated - not sure what the Clang failures are about, they
seem to be still emitting C99 when we're expecting C11 and I checked
those tests pass... maybe systems with a different C language version
default?)
This reverts commit 3c312e48f325c1b1ee11404ee6cfa08ee00037b0.
This may be a breaking change for consumers if they're trying to detect
if code is C or C++, since it'll start using new codes that they may not
be ready to recognize, in which case they may fall back to non-C
handling.
Differential Revision: https://reviews.llvm.org/D138597
