In PR #89980, DW_LNAME_HIP was not added because of a value conflict
with DW_LNAME_Assembly. The value of DW_LNAME_HIP has been updated (see
https://dwarfstd.org/languages-v6.html). This commit adds DW_LNAME_HIP.
Tests added by that PR accommodates the new SourceLanguageName.
Since YAMLIO generally knows the types ahead of time (since it primarily
functions to (de)serialize concrete C++ types) "tag resolution" isn't
really a meaningful isssue.
With MsgPackDocument we permit arbitrary documents with arbitrary type
nodes, and so the YAML "NO" problem is an issue.
Address this in MsgPackDocument itself to avoid a significant and
far-reaching backwards-incompatible change to YAMLIO (although we could
still consider tightening things up there in the future). Use the "JSON
Schema" for tag resolution where the only literals to resolve to bool by
default are "true" and "false".
In C++17, static constexpr members are implicitly inline, so they no
longer require an out-of-line definition.
Once we remove the redundant declarations, Minidump.cpp becomes
effectively empty, so this patch removes the file.
Identified with readability-redundant-declaration.
In C++17, static constexpr members are implicitly inline, so they no
longer require an out-of-line definition.
Identified with readability-redundant-declaration.
io.mapRequired takes StringRef as the key type. As such, we do not
need to create extraneous copies with str().c_str() or str().
Identified with readability-redundant-string-cstr.
Switch to the `.Cases({S0, S1, ...}, Value)` overload instead, and the
manually-enumerated overloads with 6+ arguments are getting deprecated
in https://github.com/llvm/llvm-project/pull/163405.
This pre-commits API updates ahead of the deprecation to make potential
reverts cleaner. This was already reviewed in #163405.
Currently `llvm::dwarf::LanguageDescription` returns a stringified
`DW_LNAME`. It would be useful to have an API that returns the language
name for a particular `DW_LNAME_`/version pair. LLDB's use case is that
it wants to emit diagnostics with human readable descriptions of the
language we got from debug-info (see
https://github.com/llvm/llvm-project/pull/161688). We could maintain a
side-table in LLDB but thought this might be generally useful and should
live next to the existing `LanguageDescription` API.
This PR changes the validation logic for Root Descriptor and Descriptor
Range flags to properly check if the `uint32_t` values are within range
before casting into the enums.
Originally, DXContainer `isValid...` functions were defined din the
header. That cause a problem, that made this specific file huge, since
every function also includes a `def` file. To fix this problem, this PR
moves the function to the cpp equivalent file.
Closes: [158162](https://github.com/llvm/llvm-project/issues/158162)
This reverts commit 54012102c4a8e8bba9b3b27291dab126e3521544 while I further
investigate bot failures. Apparently adding a dependence on BinaryFormat to
Object was insufficient to fix the original linker issues.
This reapplies cd32b9b6c3b, which was reverted in 25e02a43fe6 due to bot
failures.
The failures all appear to be link errors due to the Object library not
depending on BinaryFormat. This commit adds the missing dependence.
There's nothing ObjectFile specific about getArchTriple, so move it into
the BinaryFormat library so that clients can use it without taking a
dependence on libObject.
MachOObjectFile::getArchTriple is updated to call through to the moved
implementation.
These are defined in the user range until standard versions of them get
adopted into dwarf, which is expected in DWARF6.
Some of these amount to reservations currently as no code to use them is
included. It would be very helpful to get them committed to avoid
conflicts necessitating encoding changes while we are in the process of
upstreaming.
---------
Co-authored-by: Juan Martinez Fernandez <juamarti@amd.com>
Co-authored-by: Emma Pilkington <Emma.Pilkington@amd.com>
```
warning: implicit capture of 'this' with a capture default of '=' is deprecated [-Wdeprecated-this-capture]
```
Co-authored-by: Jeremy Kun <j2kun@users.noreply.github.com>
Allow assignment of float to DocType and support output of float in
writeToBlob method.
Expand tests coverage to various missing basic I/O operations.
Co-authored-by: Xavi Zhang <Xavi.Zhang@amd.com>
As part of the Root Signature Spec, we need to validate if Root
Signatures are not defining overlapping ranges.
Closes: https://github.com/llvm/llvm-project/issues/126645
---------
Co-authored-by: joaosaffran <joao.saffran@microsoft.com>
Co-authored-by: Joao Saffran <{ID}+{username}@users.noreply.github.com>
Co-authored-by: Joao Saffran <jderezende@microsoft.com>
This reapplies #152650 with a build fix for clang-11 (need explicit
template parameters for ArrayRef construction) and avoiding the
default-in-a-switch-covering-enum warning. It also adds two new tests.
The original commit message was:
The trickiest part here is that the FREs have a variable size, in two
(or three?) dimensions:
- the size of the StartAddress field. This determined by the FDE they
are in, so it is uniform across all FREs in one FDE.
- the number and sizes of offsets following the FRE. This can be
different for each FRE.
While vending this information through a template API would be possible,
I believe such an approach would be very unwieldy, and it would still
require a sequential scan through the FRE list. This is why I'm
implementing this by reading the data into a common data structure using
the fallible iterator pattern.
For more information about the SFrame unwind format, see the
[specification](https://sourceware.org/binutils/wiki/sframe) and the
related
[RFC](https://discourse.llvm.org/t/rfc-adding-sframe-support-to-llvm/86900).
The trickiest part here is that the FREs have a variable size, in two
(or three?) dimensions:
- the size of the StartAddress field. This determined by the FDE they
are in, so it is uniform across all FREs in one FDE.
- the number and sizes of offsets following the FRE. This can be
different for each FRE.
While vending this information through a template API would be possible,
I believe such an approach would be very unwieldy, and it would still
require a sequential scan through the FRE list. This is why I'm
implementing this by reading the data into a common data structure using
the fallible iterator pattern.
For more information about the SFrame unwind format, see the
[specification](https://sourceware.org/binutils/wiki/sframe) and the
related
[RFC](https://discourse.llvm.org/t/rfc-adding-sframe-support-to-llvm/86900).
During the split of the various `Frontend/HLSL` libraries, there was an
oversight to duplicate the `ResourceClassNames` definitions. This commit
simply consolidates the definitions into `DXContainer.h` as
`getResourceClasses`
This PR adds the SFrameParser class and uses it from llvm-readobj to
dump the section contents. Currently, it only supports parsing the
SFrame section header. Other parts of the section will be added in
follow-up patches.
llvm-readobj uses the same sframe flag syntax as GNU readelf, but I have
not attempted match the output format of the tool. I'm starting with the
"llvm" output format because it's easier to generate and lets us
tweak the format to make it useful for testing the generation code. If
needed, support for the GNU format could be added by overriding this
functionality in the GNU ELF Dumper.
For more information, see the [sframe
specification](https://sourceware.org/binutils/wiki/sframe) and the
related
[RFC](https://discourse.llvm.org/t/rfc-adding-sframe-support-to-llvm/86900).
This pr removes the redundancy of having the same enums defined in both
the front-end and back-end of handling root signatures. Since there are
many more uses of the enum in the front-end of the code, we will adhere
to the naming conventions used in the front-end, to minimize the diff.
The macros in `DXContainerConstants.def` are also touched-up to be
consistent and to have each macro name follow its respective definition
in d3d12.h and searchable by name
[here](https://learn.microsoft.com/en-us/windows/win32/api/d3d12/).
Additionally, the many `getEnumNames` are moved to `DXContainer` from
`HLSLRootSignatureUtils` as they we will want them to be exposed
publicly anyways.
Changes for each enum follow the pattern of a commit that will make the
enum definition in `DXContainer` adhere to above listed naming
conventions, followed by a commit to actually use that enum in the
front-end.
Resolves https://github.com/llvm/llvm-project/issues/145815
## Purpose
This patch makes a minor changes to LLVM and Clang so that LLVM can be
built as a Windows DLL with `clang-cl`. These changes were not required
for building a Windows DLL with MSVC.
## Background
The Windows DLL effort is tracked in #109483. Additional context is
provided in [this
discourse](https://discourse.llvm.org/t/psa-annotating-llvm-public-interface/85307),
and documentation for `LLVM_ABI` and related annotations is found in the
LLVM repo
[here](https://github.com/llvm/llvm-project/blob/main/llvm/docs/InterfaceExportAnnotations.rst).
## Overview
Specific changes made in this patch:
- Remove `constexpr` fields that reference DLL exported symbols. These
symbols cannot be resolved at compile time when building a Windows DLL
using `clang-cl`, so they cannot be `constexpr`. Instead, they are made
`const` and initialized in the implementation file rather than at
declaration in the header.
- Annotate symbols now defined out-of-line with `LLVM_ABI` so they are
exported when building as a shared library.
- Explicitly add default copy assignment operator for `ELFFile` to
resolve a compiler warning.
## Validation
Local builds and tests to validate cross-platform compatibility. This
included llvm, clang, and lldb on the following configurations:
- Windows with MSVC
- Windows with Clang
- Linux with GCC
- Linux with Clang
- Darwin with Clang
These are identified by misc-include-cleaner. I've filtered out those
that break builds. Also, I'm staying away from llvm-config.h,
config.h, and Compiler.h, which likely cause platform- or
compiler-specific build failures.
Adding support for Root Constant in MC, Object and obj2yaml and
yaml2obj, this PR adds:
- new structures to dxbc definition.
- serialize and desirialize logic from dxcontainer to yaml
- tests validating against dxc
- adding support to multiple parts.
Closes: https://github.com/llvm/llvm-project/issues/126633
---------
Co-authored-by: joaosaffran <joao.saffran@microsoft.com>
This adds ELF::convertTripleArchTypeToEMachine and uses it in
llvm-ifs. It handles many more Triple::ArchType values than the
old code, though not all since I couldn't quickly discern
what all the mappings are.
When creating `EnumDecl`s from DWARF for Objective-C `NS_ENUM`s, the
Swift compiler tries to figure out if it should perform "swiftification"
of that enum (which involves renaming the enumerator cases, etc.). The
heuristics by which it determines whether we want to swiftify an enum is
by checking the `enum_extensibility` attribute (because that's what
`NS_ENUM` pretty much are). Currently LLDB fails to attach the
`EnumExtensibilityAttr` to `EnumDecl`s it creates (because there's not
enough info in DWARF to derive it), which means we have to fall back to
re-building Swift modules on-the-fly, slowing down expression evaluation
substantially. This happens around
4b3931c8ce/lib/ClangImporter/ImportEnumInfo.cpp (L37-L59)
To speed up Swift exression evaluation, this patch proposes encoding the
C/C++/Objective-C `enum_extensibility` attribute in DWARF via a new
`DW_AT_APPLE_ENUM_KIND`. This would currently be only used from the LLDB
Swift plugin. But may be of interest to other language plugins as well
(though I haven't come up with a concrete use-case for it outside of
Swift).
I'm open to naming suggestions of the various new attributes/attribute
constants proposed here. I tried to be as generic as possible if we
wanted to extend it to other kinds of enum properties (e.g., flag
enums).
The new attribute would look as follows:
```
DW_TAG_enumeration_type
DW_AT_type (0x0000003a "unsigned int")
DW_AT_APPLE_enum_kind (DW_APPLE_ENUM_KIND_Closed)
DW_AT_name ("ClosedEnum")
DW_AT_byte_size (0x04)
DW_AT_decl_file ("enum.c")
DW_AT_decl_line (23)
DW_TAG_enumeration_type
DW_AT_type (0x0000003a "unsigned int")
DW_AT_APPLE_enum_kind (DW_APPLE_ENUM_KIND_Open)
DW_AT_name ("OpenEnum")
DW_AT_byte_size (0x04)
DW_AT_decl_file ("enum.c")
DW_AT_decl_line (27)
```
Absence of the attribute means the extensibility of the enum is unknown
and abides by whatever the language rules of that CU dictate.
This does feel like a big hammer for quite a specific use-case, so I'm
happy to discuss alternatives.
Alternatives considered:
* Re-using an existing DWARF attribute to express extensibility. E.g., a
`DW_TAG_enumeration_type` could have a `DW_AT_count` or
`DW_AT_upper_bound` indicating the number of enumerators, which could
imply closed-ness. I felt like a dedicated attribute (which could be
generalized further) seemed more applicable. But I'm open to re-using
existing attributes.
* Encoding the entire attribute string (i.e., `DW_TAG_LLVM_annotation
("enum_extensibility((open))")`) on the `DW_TAG_enumeration_type`. Then
in LLDB somehow parse that out into a `EnumExtensibilityAttr`. I haven't
found a great API in Clang to parse arbitrary strings into AST nodes
(the ones I've found required fully formed C++ constructs). Though if
someone knows of a good way to do this, happy to consider that too.
Remove the enum about ResourceFlag.
Add struct ResourceFlags which save the resource flags with bool fields.
This will get better yaml dump.
For #103275
In a mach_header, the cpusubtype is a 32-bit field, but it's split in 2
subfields:
- the low 24 bits containing the cpu subtype proper, (e.g.,
CPU_SUBTYPE_ARM64E 2)
- the high 8 bits containing a capability field used for additional
feature flags.
Notably, it's only the subtype subfield that participates in fat file
slice discrimination: the caps are ignored.
arm64e uses the caps subfield to encode a ptrauth ABI version:
- 0x80 (CPU_SUBTYPE_PTRAUTH_ABI) denotes a versioned binary
- 0x40 denotes a kernel-ABI binary
- 0x00-0x0F holds the ptrauth ABI version
This teaches the basic obj tools to decode that (or ignore it when
unneeded).
It also teaches the MachO writer to default to emitting versioned
binaries, but with a version of 0 (and without the kernel ABI flag).
Modern arm64e requires versioned binaries: a binary with 0x00 caps in
cpusubtype is now rejected by the linker and everything after. We can
live without the sophistication of specifying the version and kernel ABI
for now.
Co-authored-by: Francis Visoiu Mistrih <francisvm@apple.com>
This PR extends Dwarf.def to include the number of operands and the arity (the
number of entries on the DWARF stack).
- The arity is used in LLDB's DWARF expression evaluator.
- The number of operands is unused, but is present in the table to avoid
confusing the arity with the operands. Keeping the latter up to date should
be straightforward as it maps directly to a table present in the DWARF
standard.
This operation extracts a number of bits at a given offset and sign or
zero extends them, which is done by emitting it as a left shift followed
by a right shift.
This is being added for use in clang for C++ structured bindings of
bitfields that have offset or size that aren't a byte multiple. A new
operation is being added, instead of shifts being used directly, as it
makes correctly handling it in optimisations (which will be done in a
later patch) much easier.
Adjust #89280:
* ELFOSABI_LINUX is a historical alias that should not be used in new
code. readelf -h displays "UNIX - GNU" instead of "Linux".
* "OS" is inappropriate. Some values are architecture-specific, e.g.
ELFOSABI_ARM.
* Drop lowercase, which seems a job of the caller.
Add some unittests.
Pull Request: https://github.com/llvm/llvm-project/pull/90270
This patch adds DWARF constants for DW_AT_language_name and
DW_AT_language_version to Dwarf.def and Dwarf.h.
While the DWARF 6 spec is not finalized, the constants are published on
the DWARF website and considered stable, with idea being that the list
published on dwarfstd.org is the authoritative source that is being
continuously updated between DWARF revisions, as new languages are being
developed.
https://dwarfstd.org/languages-v6.html
My main motivation for adding this is to use in
https://github.com/llvm/llvm-project/pull/89981
A previous commit (82f75ed) made clang ignore .gch files that were not
Clang AST files. This broke `-gmodules`, which embeds the Clang AST into
an object file containing debug info.
This changes the probing to detect any file format recognized by
`llvm::identify_magic()` as potentially containing a Clang AST.
Previous PR: https://github.com/llvm/llvm-project/pull/69204
"hidden_dynamic_lds_size" argument will be added in the reserved section
at offset 120 of the implicit argument layout.
Add "isDynamicLDSUsed" flag to AMDGPUMachineFunction to identify if a
function uses dynamic LDS.
hidden argument will be added in below cases:
- LDS global is used in the kernel.
- Kernel calls a function which uses LDS global.
- LDS pointer is passed as argument to kernel itself.
Summary:
More SPIR-V related patches are being upstreamed. We should add support
to detect when a binary file is SPIR-V. This will be used in the future
when support for SPIR-V is added to the offloading runtime or more
support for bundling.
The magic number is described in the official documentation:
https://registry.khronos.org/SPIR-V/specs/1.0/SPIRV.html#Magic. Notably,
SPIR-V files are streams of 32-bit words. This means that the magic
numbers differ depending on the endianness. Here we simply check the
strandard and byte-reversed versions.
This patch replaces uses of StringRef::{starts,ends}with with
StringRef::{starts,ends}_with for consistency with
std::{string,string_view}::{starts,ends}_with in C++20.
I'm planning to deprecate and eventually remove
StringRef::{starts,ends}with.
