This adds support for `S_DEFRANGE_REGISTER_REL_INDIR` (as
`DefRangeRegisterRelIndirSym`).
It's to `S_REGREL32_INDIR` what `S_DEFRANGE_REGISTER_REL` is to
`S_REGREL32`. `S_REGREL32_INDIR` was added in #183172.
LLVM only generates `S_LOCAL` for variables and parameters, so we need
this record to specify a range where a variable is indirectly accessed.
I didn't find any PDB where this record is in, so I guessed the layout
based on `S_DEFRANGE_REGISTER_REL` and `S_REGREL32_INDIR`. Locally, I
updated LLVM to generate this where possible, and tested it with the VS
debugger and WinDBG. Both handled the record correctly. This PR doesn't
include the change to debug info generation yet - you can find the
current WIP in
884072fa17.
The name `OffsetInUdt` comes from DIA
([`get_offsetInUdt`](https://learn.microsoft.com/en-us/visualstudio/debugger/debug-interface-access/idiasymbol-get-offsetinudt?view=visualstudio)).
Given that this symbol also has a `offsetInParent`, I find the name a
bit confusing. When generating the record in the commit above, I used
the name `DerefOffset`. If we change it here, it should be changed in
`RegRelativeIndirSym` as well.
This adds `RegRelativeIndirSym` (`S_REGREL32_INDIR`) as a record, so we
can emit and dump it (#34392). It encodes a variable at the location
`*($Register+ Offset) + OffsetInUdt` and is used by MSVC in C++ 20
coroutines and C++ 17 structured bindings. Clang also needs this for
coroutines (for `__promise` which has the location `DW_OP_deref,
DW_OP_plus_uconst, 16`).
For example:
```cpp
struct Foo { int a, b; };
void fn() {
Foo f = {1, 2};
// ╰─ S_REGREL32{ reg = rsp, offset = 0 }
auto &[x, y] = f;
// │ ╰─ S_REGREL32_INDIR{ reg = rsp, offset = 8, offset-in-udt = 4, type = int }
// ╰─ S_REGREL32_INDIR{ reg = rsp, offset = 8, offset-in-udt = 0, type = int }
}
```
The `S_REGREL32_INDIR` for `y` from above looks like this:
```
│ 08000000 │ 74000000 │ 04000000 │ 4F01 │ 7900 │
│ Offset │ Type │ OffInUdt │ Reg. │ Name │
```
I prototyped support for this in LLDB's native PDB parser to check the
assumption about the location (in a followup PR).
I was wrong in #182743, thinking that the location was just `$Register +
Offset + OffsetInUdt`. That could've been encoded as a `S_REGREL32`.
Presumably, `S_BPREL32_INDIR` works similar, but I can't get MSVC to
generate this.
Currently, WASM symbols taken from the export section of shared objects
lose their flags. This can result in link failures. For example, if a
TLS symbol is exported from a shared object, relocation fails because
`wasm-ld` thinks that the symbol is not flagged as a TLS symbol.
This PR populates symbol flags for symbols in the export section from
the flags stored in the dylink0 section.
The export info section was also not serialized by the WASM emitter for
YAML, which this PR fixes
When new record types or leaf kinds are added to CodeView, then we
should try to dump all the information we have on these records.
- If a type or symbol is unknown, the raw data is now always shown.
Before, you'd have to set `--sym-data` or `--type-data` (but that would
show it for all types).
- Converting to/from YAML, unknown records are now included. Before we'd
error out.
I stumbled upon this when checking PDBs from C++ 20 coroutines compiled
with MSVC. These contain the symbol records `0x1171` and `0x117c`, which
we don't handle yet.
This PR updates the OffloadBinary format from version 1 to version 2,
enabling support for multiple offloading entries in a single binary.
This allows combining multiple device images into a single binary with
common global metadata while maintaining backwards compatibility with
version 1 binaries.
# Key Changes
## Binary Format Enhancements
**Version 2 Format Changes:**
- Changed from single-entry to multi-entry design
- Updated `Header` structure:
- Renamed `EntryOffset` → `EntriesOffset` (offset to entries array)
- Renamed `EntrySize` → `EntriesCount` (number of entries)
- Added `StringEntry::ValueSize` field to support explicit string value
sizes (enables non-null-terminated strings)
- Introduced `OffloadEntryFlags` enum with `OIF_Metadata` flag for
metadata-only entries (entries without binary images)
**API Changes:**
- `OffloadBinary::create()` now returns
`Expected<SmallVector<std::unique_ptr<OffloadBinary>>>` instead of
single binary
- Added optional `Index` parameter to extract specific entry:
`create(Buffer, std::optional<uint64_t> Index)`
- `OffloadBinary::write()` now accepts `ArrayRef<OffloadingImage>`
instead of single image
- Added `OffloadBinary::extractHeader()` for header extraction
**Memory Management:**
- Implemented `SharedMemoryBuffer` class to enable memory sharing across
multiple `OffloadBinary` instances from the same file
- Multiple entries from a single serialized binary share the underlying
buffer
## Testing
**Unit Tests (`unittests/Object/OffloadingTest.cpp`):**
- `checkMultiEntryBinaryExtraction`: Tests extracting all entries from a
multi-entry binary
- `checkIndexBasedExtraction`: Tests extracting specific entries by
index, including out-of-bounds validation
- `checkEdgeCases`: Tests edge cases including:
- Empty string metadata
- Empty image data
- Large string values (4KB)
**Other Tests:**
- Updated `test/ObjectYAML/Offload/multiple_members.yaml` to include
metadata-only entry
---------
Co-authored-by: Joseph Huber <huberjn@outlook.com>
The annotation data for `S_INLINESITE` symbols was missing in YAML. This
caused PDBs with inline sites to have incorrect symbol offsets, because
`S_INLINESITE` wouldn't have the same size after creating a PDB from
YAML.
I kept the annotations as binary, because that's how they're represented
in LLVM.
In this PR I'm changing the way we provide the missing functions like
strnlen() on z/OS from the separate header file to a wrapper around the
system headers that declare these functions. This will be less
intrusive.
---------
Co-authored-by: Zibi Sarbinowski <zibi@ca.ibm.com>
yaml2obj would crash when processing Mach-O load commands with cmdsize
smaller than the actual structure size e.g. LC_SEGMENT_64 with
cmdsize=56 instead of 72. The crash occurred due to integer underflow
when calculating padding: cmdsize - BytesWritten wraps to a large value
when negative, causing a massive allocation attempt.
We can drop .str().c_str() here because all of the following are of
type StringRef:
- E.Name
- the second parameter of llvm::yaml::IO::enumCase
- the second parameter of llvm::yaml::IO::bitSetCase
Identified with readability-redundant-string-cstr.
In C++17, static constexpr members are implicitly inline, so they no
longer require an out-of-line definition.
Identified with readability-redundant-declaration.
We have optimized the implementation of introducing the "matching and
inference" technique into Propeller. In this new implementation, we have
made every effort to avoid introducing new compilation parameters while
ensuring compatibility with Propeller's current usage. Instead of
creating a new profile format, we reused the existing one employed by
Propeller. This new implementation is fully compatible with Propeller's
current usage patterns and reduces the amount of code changes. For
detailed information, please refer to the following RFC:
https://discourse.llvm.org/t/rfc-adding-matching-and-inference-functionality-to-propeller/86238.
We plan to submit the relevant changes in several pull requests (PRs).
The current one is the first PR, which adds the basic block hash to the
SHT_LLVM_BB_ADDR_MAP section.
co-authors: lifengxiang1025 <lifengxiang@kuaishou.com>; zcfh
<wuminghui03@kuaishou.com>
Co-authored-by: lifengxiang1025 <lifengxiang@kuaishou.com>
Co-authored-by: zcfh <wuminghui03@kuaishou.com>
Co-authored-by: Rahman Lavaee <rahmanl@google.com>
This patch updates the frontend to support version 1.2 of root
signatures, it adds parsing, metadata generation and a few tests.
---------
Co-authored-by: joaosaffran <joao.saffran@microsoft.com>
yaml2obj should determine the program header offset (and other
properties) based on the intended values rather than the final
`sh_offset` of the section header.
`setProgramHeaderLayout` uses section offsets for determining
`p_offset`. Move section header overriding after
`setProgramHeaderLayout` to prevent `ShOffset` from affecting program
header `p_offset`.
This change adjusts the timing of when the section header is overridden
to ensure that the program headers are set correctly.
More details
[here](https://github.com/llvm/llvm-project/pull/126537#issuecomment-2700421989).
---------
Signed-off-by: Ruoyu Qiu <cabbaken@outlook.com>
Signed-off-by: Ruoyu Qiu <qiuruoyu@xiaomi.com>
Co-authored-by: Ruoyu Qiu <qiuruoyu@xiaomi.com>
We have two forms of write:
template <typename value_type, std::size_t alignment = unaligned>
inline void write(void *memory, value_type value, endianness endian)
template <typename value_type, endianness endian, std::size_t alignment>
inline void write(void *memory, value_type value)
The difference is that endian is a function parameter in the former
but a template parameter in the latter.
This patch streamlines the code by migrating the use of the latter to
the former while deprecating the latter.
I'm planning to do the same for byte_swap and read in follow-up
patches to keep this patch simple and small.
MC Static Samplers Representation currently depends on Object
structures. This PR removes that dependency and in order to facilitate
removing to_underlying usage in follow-up PRs.
MC Descriptor Range Representation currently depend on Object
structures. This PR removes that dependency and in order to facilitate
removing to_underlying usage in follow-up PRs.
This pr fixes some inconsistencies in behaviour of how we handle
`StaticSamplersOffset` with respect to DXC and `RootParameterOffset`.
Namely:
1. Make codegen of `RTS0` always compute the `StaticSamplersOffset`
regardless if there are any `StaticSampler`s. This is to be consistent
and produce an identical `DXContainer` as DXC.
2. Make the `StaticSamplersOffset` and `RootParametersOffset` optional
parameters in the yaml description. This means it will be used when it
is specified (which was not necassarily the case before).
3. Enforce that the provided `StaticSamplersOffset` and
`RootParametersOffset` in a yaml description match the computed value.
For more context see:
https://github.com/llvm/llvm-project/issues/155299.
Description of existing test updates updates:
- `CodeGen/DirectX/ContainerData`: Updated to codegen computed values
(previously unspecified)
- `llvm-objcopy/DXContainer`: Updated to `yaml2obj` computed values
(previously unspecified)
- `ObjectYAML/DXContainer`: Updated to `yaml2obj` computed values
(previously incorrect)
- `ObjectYAML/DXContainerYAMLTest`: Updated to `yaml2obj` computed
values (previously incorrect)
See newly added tests for testing of optional parameter functionality
and `StaticSamplersOffset` computation.
Resolves: https://github.com/llvm/llvm-project/issues/155299
This patch is refactoring Root Parameter Header in DX Container backend
to remove the usage of `to_underlying`. This requires some changes:
first, MC Root Signature should not depend on Object/DXContainer.h;
Second, we need to assume data to be valid in scenarios where it was
originally not expected, this made some tests be removed.
This PR simply moves the callsite anchors from the beginning of
callsites to their end.
Emitting the end of callsites is more sensible as it allows breaking the
basic block into subblocks which end with control transfer instructions.
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
(This is a re-do of #138972, which had a minor warning in `Clang.cpp`.)
This PR adds some of the support needed for Windows hot-patching.
Windows implements a form of hot-patching. This allows patches to be
applied to Windows apps, drivers, and the kernel, without rebooting or
restarting any of these components. Hot-patching is a complex technology
and requires coordination between the OS, compilers, linkers, and
additional tools.
This PR adds support to Clang and LLVM for part of the hot-patching
process. It enables LLVM to generate the required code changes and to
generate CodeView symbols which identify hot-patched functions. The PR
provides new command-line arguments to Clang which allow developers to
identify the list of functions that need to be hot-patched. This PR also
allows LLVM to directly receive the list of functions to be modified, so
that language front-ends which have not yet been modified (such as Rust)
can still make use of hot-patching.
This PR:
* Adds a `MarkedForWindowsHotPatching` LLVM function attribute. This
attribute indicates that a function should be _hot-patched_. This
generates a new CodeView symbol, `S_HOTPATCHFUNC`, which identifies any
function that has been hot-patched. This attribute also causes accesses
to global variables to be indirected through a `_ref_*` global variable.
This allows hot-patched functions to access the correct version of a
global variable; the hot-patched code needs to access the variable in
the _original_ image, not the patch image.
* Adds a `AllowDirectAccessInHotPatchFunction` LLVM attribute. This
attribute may be placed on global variable declarations. It indicates
that the variable may be safely accessed without the `_ref_*`
indirection.
* Adds two Clang command-line parameters: `-fms-hotpatch-functions-file`
and `-fms-hotpatch-functions-list`. The `-file` flag may point to a text
file, which contains a list of functions to be hot-patched (one function
name per line). The `-list` flag simply directly identifies functions to
be patched, using a comma-separated list. These two command-line
parameters may also be combined; the final set of functions to be
hot-patched is the union of the two sets.
* Adds similar LLVM command-line parameters:
`--ms-hotpatch-functions-file` and `--ms-hotpatch-functions-list`.
* Adds integration tests for both LLVM and Clang.
* Adds support for dumping the new `S_HOTPATCHFUNC` CodeView symbol.
Although the flags are redundant between Clang and LLVM, this allows
additional languages (such as Rust) to take advantage of hot-patching
support before they have been modified to generate the required
attributes.
Credit to @dpaoliello, who wrote the original form of this patch.
