| Age | Commit message (Collapse) | Author |
|---|
|
(#165924)
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.
|
|
(#160184)
This PR is updating `Object/DXContainer.h` so that we can read data from
root signature version 1.2, which adds flags into static samplers.
|
|
of uint (#154827)
This PR is updating Root Signature YAML to use enums, this is a required
change to remove the use of to_underlying from DirectXContainer binary
file.
Closes: [#150676](https://github.com/llvm/llvm-project/issues/150676)
|
|
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.
|
|
behaviour consistent (#155521)
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
|
|
Parameter Header (#154249)
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.
|
|
- Adds support for static samplers ins dxcontainer binary format.
- Adds writing logic to mcdxbc
- adds reading logic to Object
- adds tests
Closes: [126636](https://github.com/llvm/llvm-project/issues/126636)
---------
Co-authored-by: joaosaffran <joao.saffran@microsoft.com>
|
|
obj2yaml/yaml2obj (#138315)
Closes:
https://github.com/orgs/llvm/projects/4/views/22?sliceBy%5Bvalue%5D=joaosaffran&pane=issue&itemId=97332852&issue=llvm%7Cllvm-project%7C126635
---------
Co-authored-by: joaosaffran <joao.saffran@microsoft.com>
|
|
closes: [126634](https://github.com/llvm/llvm-project/issues/126634)
---------
Co-authored-by: joaosaffran <joao.saffran@microsoft.com>
|
|
This PR revises the descriptions of DXIL module flags.
Descriptions such as `D3D11_1_SB_GLOBAL_FLAG_SKIP_OPTIMIZATION` are
referring to Global Flags in DXBC.
DXBC is not a supported backend target, so references to DXBC should not
be present.
There is also confusion with regards to the description of the
`LowPrecisionPresent` DXIL module flag, which currently reads
`D3D11_1_SB_GLOBAL_FLAG_ENABLE_MINIMUM_PRECISION` and implies the use of
minimum-precision to handle 16-bit types.
However this is not true, because both the flags `LowPrecisionPresent`
and `UseNativeLowPrecision` can simultaneously be set in the same DXIL
module, and minimum precision mode is mutually exclusive with native low
precision.
This PR revises the description of the `LowPrecisionPresent` flag to
accurately describe what it represents.
|
|
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>
|
|
(#126080)
This is the first step of adding RPATH support for wasm.
See corresponding update to the WebAssembly/tool-conventions repo on dynamic
linking: https://github.com/WebAssembly/tool-conventions/pull/246
|
|
This PR adds:
- `RootSignatureFlags` extraction from DXContainer using `obj2yaml`
This PR is part of: #121493
---------
Co-authored-by: joaosaffran <joao.saffran@microsoft.com>
|
|
(#125739)" (#125786)
This reverts commit c798a5c4d5c3c8cb21e6001f505d8f44217c2244.
This broke bunch of test the emscripten side. Reverting while we
investigate.
|
|
Fixes: #58555
|
|
Size is required, so we don't know if it's in
uninitialized state after the previous error.
Triggers msan on llvm/test/tools/yaml2obj/ELF/custom-fill.yaml NOSIZE
test.
We have `Fill` Section with Pattern, but no size. Before the fix it
produced error:
```
YAML:169:5: error: missing required key 'Size'
- Type: Fill
^
YAML:169:5: error: "Size" can't be 0 when "Pattern" is not empty
- Type: Fill
```
The same applies to `MachOYAML::Section` fields `content` and `size`.
However `MachOYAML::Section` matches size first, so on error,
content is not set anyway. Added error checking just in case.
|
|
This has not been emitted since
https://github.com/llvm/llvm-project/commit/3f34e1b883351c7d98426b084386a7aa762aa366.
The corresponding proposed tool-conventions change:
https://github.com/WebAssembly/tool-conventions/pull/236
|
|
Remove the enum about ResourceFlag.
Add struct ResourceFlags which save the resource flags with bool fields.
This will get better yaml dump.
For #103275
|
|
Add ResourceType, ResourceKind and ResourceFlag enum class for PSV
resource.
This is for #103275
|
|
files. (#102978)
This change is enough to allow `--strip-debug` to work on object files,
without breaking the relocation information or symbol table.
A more complete version of this change would instead reconstruct the
symbol table and relocation sections, but that is much larger change.
Bug: #102002
|
|
This change introduces a version 3 of the PSV data that includes support
for the name of the entry function as an offset into StringTable data to
a null-terminated utf-8 string.
Additional tests were added to ensure that the new value was properly
serialized/deserialized from object data.
Fixes #80175
---------
Co-authored-by: Cooper Partin <coopp@ntdev.microsoft.com>
|
|
This reverts commit cde54df39cab3a1d60a3e1862ab341609bee3cc3.
Co-authored-by: Cooper Partin <coopp@ntdev.microsoft.com>
|
|
This change introduces a version 3 of the PSV data that includes support
for the name of the entry function as an offset into StringTable data to
a null-terminated utf-8 string.
Additional tests were added to ensure that the new value was properly
serialized/deserialized from object data.
Fixes #80175
---------
Co-authored-by: Cooper Partin <coopp@ntdev.microsoft.com>
|
|
For DirectX, program signatures are encoded into three different binary
sections depending on if the signature is for inputs, outputs, or
patches. All three signature types use the same data structure encoding
so they can share a lot of logic.
This patch adds support for reading and writing program signature data
as both yaml and binary data.
Fixes #57743 and #57744
|
|
The DXContainer pipeline state information encodes a bunch of mask
vectors that are used to track things about the inputs and outputs from
each shader.
This adds support for reading and writing them throught he YAML test
interfaces. The writing logic in MC is extremely primitive and we'll
want to revisit the API for that, but since I'm not sure how we'll want
to generate the mask bits from DXIL during code generation I didn't want
to spend too much time on the API.
Fixes #59479
|
|
The pipeline state data captured in the PSV0 section of the DXContainer
file encodes signature elements which are read by the runtime to map
inputs and outputs from the GPU program.
This change adds support for generating and parsing signature elements
with testing driven through the ObjectYAML tooling.
Reviewed By: bogner
Differential Revision: https://reviews.llvm.org/D157671
Initially landed as 8c567e64f808f7a818965c6bc123fedf7db7336f, and
reverted in 4d800633b2683304a5431d002d8ffc40a1815520.
../llvm/include/llvm/BinaryFormat/DXContainerConstants.def
../llvm/test/ObjectYAML/DXContainer/PSVv1-amplification.yaml
../llvm/test/ObjectYAML/DXContainer/PSVv1-compute.yaml
../llvm/test/ObjectYAML/DXContainer/PSVv1-domain.yaml
../llvm/test/ObjectYAML/DXContainer/PSVv1-geometry.yaml
../llvm/test/ObjectYAML/DXContainer/PSVv1-vertex.yaml
../llvm/test/ObjectYAML/DXContainer/PSVv2-amplification.yaml
../llvm/test/ObjectYAML/DXContainer/PSVv2-compute.yaml
../llvm/test/ObjectYAML/DXContainer/PSVv2-domain.yaml
../llvm/test/ObjectYAML/DXContainer/PSVv2-geometry.yaml
../llvm/test/ObjectYAML/DXContainer/PSVv2-vertex.yaml
|
|
This reverts commit 8c567e64f808f7a818965c6bc123fedf7db7336f.
|
|
The pipeline state data captured in the PSV0 section of the DXContainer
file encodes signature elements which are read by the runtime to map
inputs and outputs from the GPU program.
This change adds support for generating and parsing signature elements
with testing driven through the ObjectYAML tooling.
Reviewed By: bogner
Differential Revision: https://reviews.llvm.org/D157671
|
|
Previously when objcopy generated section headers, it padded the LEB
that encodes the section size out to 5 bytes, matching the behavior of
clang. This is correct, but results in a binary that differs from the
input. This can sometimes have undesirable consequences (e.g. breaking
source maps).
This change makes the object reader remember the size of the LEB
encoding in the section header, so that llvm-objcopy can reproduce it
exactly. For sections not read from an object file (e.g. that
llvm-objcopy is adding itself), pad to 5 bytes.
Reviewed By: jhenderson
Differential Revision: https://reviews.llvm.org/D155535
|
|
When writing this initially I missed including the resource stride.
This change adds the resources stride to the serialized value.
I've also extended the testing and error reporting around parsing PSV
information. This adds tests to verify that the reader produces
meaningful error messages for malformed DXContainer files, and a test
that verifies the resource stride is respected in the reader even if
the stride isn't an expected or known value (as would happen if the
format changes in the future).
This is part of #59479.
Reviewed By: bogner, bob80905
Differential Revision: https://reviews.llvm.org/D155143
|
|
clang -ffat-lto-objects can use this new ELF section type for the .llvm.lto
section for fat LTO support (D146776).
Original RFC: https://discourse.llvm.org/t/rfc-ffat-lto-objects-support/63977
Reviewed By: jhenderson
Differential Revision: https://reviews.llvm.org/D153215
|
|
This patch continues implementing DirectX pipeline state validation
information by adding support for resource binding metadata.
Reviewed By: python3kgae
Differential Revision: https://reviews.llvm.org/D143130
|
|
DirectX shader pipeline state validation information is a fairly
complicated to serialize data structure. This patch adds the first bit
of support for reading and writing the runtime info structure which
comes first in the encoded data.
Subsequent patches will flesh out the remaining fields of the data
structure.
There is no official documentation for the format, but the format is
roughly documented in the code comment here:
https://github.com/microsoft/DirectXShaderCompiler/blob/main/include/dxc
/DxilContainer/DxilPipelineStateValidation.h#L731
Reviewed By: python3kgae
Differential Revision: https://reviews.llvm.org/D141649
|
|
Before:
```
wrote too much data somewhere, section offsets don't line up
```
After:
```
wrote too much data somewhere, section offsets in section __debug_str for segment __DWARF don't line up: [cursor=0x581], [fileStart=0x0], [sectionOffset=0x579]
```
Differential Revision: https://reviews.llvm.org/D140116
|
|
The exports trie used to be pointed by the information in LC_DYLD_INFO,
but when chained fixups are present, the exports trie is pointed by
LC_DYLD_EXPORTS_TRIE instead.
Modify the Object library to give access to the information pointed by
each of the load commands, and to fallback from one into the other when
the exports are requested.
Modify ObjectYAML to support dumping the export trie when pointed by
LC_DYLD_EXPORTS_TRIE and to parse the existence of a export trie also
when the load command is present.
This is a split of D134250 with improvements on top.
Reviewed By: alexander-shaposhnikov
Differential Revision: https://reviews.llvm.org/D134571
|
|
Add basic binary support for chained fixups. This allows basic tests
with chained fixups without trying to create a format for them until the
work on the Object library is considered finished.
Reviewed By: pete
Differential Revision: https://reviews.llvm.org/D134250
|
|
This is a split of D134250.
Supports for parsing and dumping the LC_DATA_IN_CODE contents (as binary
data).
This allows more complete testing of llvm-objdump in D133974.
Reviewed By: Higuoxing
Differential Revision: https://reviews.llvm.org/D134569
|
|
The `dumpExportEntry` was dumping everything using signed LEB128, but
the format seems to use unsigned LEB128. This can be cross-checked with
the implementation in MachOObjectFile.cpp, the implementation in LLD's
ExportTrie.cpp, and the implementation in macho2yaml.cpp, which all use
ULEB128 functions..
The difference is only apparent when encoding some values with specific
bit patterns (bit active in the 7th, 14th, ... bits of the binary). The
encoding was not always creating problems in the resulting binaries
because if the extra byte was part of the padding, the result of
decoding it as ULEB128 is the same as decoding as SLEB128, however, the
code of MachOObjectFile.cpp (used by llvm-objdump) checks the buffer
decoding position against the reported length, which triggered an error.
Modified a test that used an address with this pattern (0x3FA0, the 14th
bit is active), to show that a round trip still produces the same
results, and added a check using llvm-objdump to use their extra checks
to verify this implementation.
Reviewed By: pete
Differential Revision: https://reviews.llvm.org/D134563
|
|
-o is very common among tools. yaml2obj supports -o and it surprised me that
obj2yaml doesn't support -o. Just add it which doesn't take much code.
Differential Revision: https://reviews.llvm.org/D129713
|
|
Currently we use the `.llvm.offloading` section to store device-side
objects inside the host, creating a fat binary. The contents of these
sections is currently determined by the name of the section while it
should ideally be determined by its type. This patch adds the new
`SHT_LLVM_OFFLOADING` section type to the ELF section types. Which
should make it easier to identify this specific data format.
Reviewed By: jhenderson
Differential Revision: https://reviews.llvm.org/D129052
|
|
This patchs adds the necessary code for inspecting or creating offloading
binaries using the standing `obj2yaml` and `yaml2obj` features in LLVM.
Depends on D127774
Reviewed By: jhenderson
Differential Revision: https://reviews.llvm.org/D127776
|
|
This change continues to lay the ground work for supporting extended
const expressions in the linker.
The included test covers object file reading and writing and the YAML
representation.
Differential Revision: https://reviews.llvm.org/D121349
|
|
This wasn't running because of the missing colon
|
|
This adds support for encoding and decoding the LC_FUNCTION_STARTS load
command payload.
Differential Revision: https://reviews.llvm.org/D119205
|
|
Tools such as `llvm-objdump` or `llvm-readobj` support indirect symbol
tables. Here, support it for `obj2yaml` and `yaml2obj`.
Reviewed By: jhenderson, drodriguez
Differential Revision: https://reviews.llvm.org/D114410
|
|
This removes `WasmTagType`. `WasmTagType` contained an attribute and a
signature index:
```
struct WasmTagType {
uint8_t Attribute;
uint32_t SigIndex;
};
```
Currently the attribute field is not used and reserved for future use,
and always 0. And that this class contains `SigIndex` as its property is
a little weird in the place, because the tag type's signature index is
not an inherent property of a tag but rather a reference to another
section that changes after linking. This makes tag handling in the
linker also weird that tag-related methods are taking both `WasmTagType`
and `WasmSignature` even though `WasmTagType` contains a signature
index. This is because the signature index changes in linking so it
doesn't have any info at this point. This instead moves `SigIndex` to
`struct WasmTag` itself, as we did for `struct WasmFunction` in D111104.
In this CL, in lib/MC and lib/Object, this now treats tag types in the
same way as function types. Also in YAML, this removes `struct Tag`,
because now it only contains the tag index. Also tags set `SigIndex` in
`WasmImport` union, as functions do.
I think this makes things simpler and makes tag handling more in line
with function handling. These two shares similar properties in that both
of them have signatures, but they are kind of nominal so having the same
signature doesn't mean they are the same element.
Also a drive-by fix: the reserved 'attirubute' part's encoding changed
from uleb32 to uint8 a while ago. This was fixed in lib/MC and
lib/Object but not in YAML. This doesn't change object files because the
field's value is always 0 and its encoding is the same for the both
encoding.
This is effectively NFC; I didn't mark it as such just because it
changed YAML test results.
Reviewed By: sbc100, tlively
Differential Revision: https://reviews.llvm.org/D111086
|
|
This format is based on sub-sections (like the "linking" and "name"
sections) and is therefore easier to extend going forward.
spec change: https://github.com/WebAssembly/tool-conventions/pull/170
binaryen change: https://github.com/WebAssembly/binaryen/pull/4141
wabt change: https://github.com/WebAssembly/wabt/pull/1707
emscripten change: https://github.com/emscripten-core/emscripten/pull/15019
Differential Revision: https://reviews.llvm.org/D109595
|
|
The new name is conciser and matches yaml2obj ELF & DWARF.
Reviewed By: #lld-macho, thakis
Differential Revision: https://reviews.llvm.org/D106759
|
|
We recently decided to change 'event' to 'tag', and 'event section' to
'tag section', out of the rationale that the section contains a
generalized tag that references a type, which may be used for something
other than exceptions, and the name 'event' can be confusing in the web
context.
See
- https://github.com/WebAssembly/exception-handling/issues/159#issuecomment-857910130
- https://github.com/WebAssembly/exception-handling/pull/161
Reviewed By: tlively
Differential Revision: https://reviews.llvm.org/D104423
|
|
order.
This fixes https://bugs.llvm.org/show_bug.cgi?id=41712 bug.
Reviewed By: aganea
Differential Revision: https://reviews.llvm.org/D99978
|
