| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
`EM_INTEL205` was renamed to `EM_INTELGT` (ref
[here](https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=7b9f985957798ba4dacc454f22c9e426c6897cb8))
and is used for Intel GPU images.
We will be using this type for offloading to Intel GPUs.
---------
Signed-off-by: Sarnie, Nick <nick.sarnie@intel.com>
|
|
Planning to add to the list in
https://github.com/llvm/llvm-project/pull/159791, so format it.
Signed-off-by: Sarnie, Nick <nick.sarnie@intel.com>
|
|
|
|
Summary:
Turns out the new CUDA ABI now applies retroactively to all the other
SMs if you upgrade to CUDA 13.0. This patch changes the scheme, keeping
all the SM flags consistent but using an offset.
Fixes: https://github.com/llvm/llvm-project/issues/159088
|
|
Previously, llvm-readelf dumped hex format values in different ways.
Some of them were printed in upper-case, while the others were in
lower-case format. This change switches the format to lower-case in all
cases.
Why is this useful? As an example, FileCheck comparisons are
case-sensitive by default. This change means it's easier to compare
those values, because they have the same format.
|
|
runtime pseudo-relocation records (#151816)
MinGW toolchain uses "runtime pseudo-relocation" mechanism to support
auto-importing symbols from DLLs.
There is no commonly used tools for dump the pseudo-relocation records,
so we implement that functionality in llvm-readobj.
|
|
(#155041)
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.
|
|
The sframe generator needs to construct this word separately from FDEs
themselves, so split them into a separate data structure.
|
|
If there is a relocation for a particular FDE, print it as well. This is
mainly meant for human consumption (otherwise, there's no way to tell
which function a given (relocatable) FDE refers to). For testing of
relocation generation, I'd still recommend using the regular relocation
dumper, as this code will not detect (e.g.) any superfluous relocations.
I've considered handling relocations inside the SFrameParser class, but
I couldn't find an elegant way to do that. Right now, I don't have a use
case for resolving relocations there as lldb (my other use case for
SFrameParser) will always operate on linked objects.
|
|
(#152695)
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).
|
|
Reverts llvm/llvm-project#151301 - build breakage on multiple bots.
|
|
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).
|
|
Addr is already of const uint8_t *.
|
|
|
|
Also known as Function Description Entries. The entries occupy a
contiguous piece of the section, so the code is mostly straight-forward.
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).
|
|
- Added `IMAGE_DLL_CHARACTERISTICS_EX_CET_COMPAT_STRICT_MODE`
- Added
`IMAGE_DLL_CHARACTERISTICS_EX_CET_SET_CONTEXT_IP_VALIDATION_RELAXED_MODE`
- Added
`IMAGE_DLL_CHARACTERISTICS_EX_CET_DYNAMIC_APIS_ALLOW_IN_PROC_ONLY`
- Added `IMAGE_DLL_CHARACTERISTICS_EX_CET_RESERVED_1`
- Added `IMAGE_DLL_CHARACTERISTICS_EX_CET_RESERVED_2`
- Added `IMAGE_DLL_CHARACTERISTICS_EX_FORWARD_CFI_COMPAT`
- Added `IMAGE_DLL_CHARACTERISTICS_EX_HOTPATCH_COMPATIBLE`
|
|
Summary:
We rely on these flags to do things in the runtime and print the
contents of binaries correctly. CUDA updated their ABI encoding recently
and we didn't handle that. it's a new ABI entirely so we just select on
it when it shows up.
Fixes: https://github.com/llvm/llvm-project/issues/148703
|
|
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).
|
|
|
|
Reference:
https://sourceware.org/git/?p=gnu-gabi.git;a=blob;f=program-loading-and-dynamic-linking.txt;h=3357d865720285df2d29c4e8f92de49ddf1beb40;hb=refs/heads/master
|
|
TmpSecPtr is already of const uint8_t *.
|
|
newly-introduced SHT_LLVM_BB_ADDR_MAP version. (#144426)
Recently, we have been looking at some optimizations targeting
individual calls. In particular, we plan to extend the address mapping
technique to map to individual callsites. For example, in this piece of
code for a basic blocks:
```
<BB>:
1200: lea 0x1(%rcx), %rdx
1204: callq foo
1209: cmpq 0x10, %rdx
120d: ja L1
```
We want to emit 0x9 as the call site offset for `callq foo` (the offset
from the block entry to right after the call), so that we know if a
sampled address is before the call or after.
This PR implements the decode/encode/emit capability. The Codegen change
will be implemented in a later PR.
|
|
This is just a stub for now.
|
|
CFIPrograms' most common uses are within debug frames, but it is not
their only use. For example, some assembly writers encode them by hand
into .cfi_escape directives. This PR extracts printing code for them
into its own files, which avoids the need for the main class to depend
on DWARFUnit, sections, and similar.
One in a series of NFC DebugInfo/DWARF refactoring changes to layer it
more cleanly, so that binary CFI parsing can be used from low-level
code, (such as byte strings created via .cfi_escape) without circular
dependencies. The final goal is to make a more limited dwarf library
usable from lower-level code.
More information can be found at
https://discourse.llvm.org/t/rfc-debuginfo-dwarf-refactor-into-to-lower-and-higher-level-libraries/86665
|
|
|
|
|
|
|
|
In order to support the AArch64 ABI, Microsoft has extended the unwinder
to support additional opcodes. (Updated documentation at
https://learn.microsoft.com/en-us/cpp/build/arm64-exception-handling .)
First in a series of patches to support SVE on Windows.
|
|
|
|
ELFAtributeParser and add support for AArch64 Build Attributes (#128727)
Refactor readobj to integrate AArch64 Build Attributes under
ELFAttributeParser. ELFAttributeParser now serves as a base class for:
- ELFCompactAttrParser, handling Arm-style attributes with a single
build attribute subsection.
- ELFExtendedAttrParser, handling AArch64-style attributes with multiple
build attribute subsections. This improves code organization and better
aligns with the attribute parsing model.
Add support for parsing AArch64 Build Attributes.
|
|
|
|
and fix crash when vd_aux is invalid (#86611).
vd_version, vd_flags, vd_ndx, and vd_cnt in Elf{32,64}_Verdef are
16-bit. Change VerDef to use uint16_t instead.
vda_name specifies a NUL-terminated string. Update getVersionDefinitions
to remove some `.c_str()`.
Pull Request: https://github.com/llvm/llvm-project/pull/128434
|
|
gfx940 and gfx941 are no longer supported. This is one of a series of
PRs to remove them from the code base.
This PR removes all non-documentation occurrences of gfx940/gfx941 from
the llvm directory, and the remaining occurrences in clang.
Documentation changes will follow.
For SWDEV-512631
|
|
Add support for the new SHF_AARCH64_PURECODE ELF section flag:
https://github.com/ARM-software/abi-aa/pull/304
The general implementation follows the existing one for ARM targets.
Generating object files with the `SHF_AARCH64_PURECODE` flag set is
enabled by the `+execute-only` target feature.
Related PRs:
* Clang: https://github.com/llvm/llvm-project/pull/125688
* LLD: https://github.com/llvm/llvm-project/pull/125689
|
|
This patch updates the getSectionAndRelocations function to also support
CREL relocation sections. Unit tests have been added. This patch also
updates consumers to say they explicitly do not support CREL format
relocations. Subsequent patches will make the consumers work with CREL
format relocations and also add in testing support.
Reviewers: red1bluelost, MaskRay, rlavaee
Reviewed By: MaskRay
Pull Request: https://github.com/llvm/llvm-project/pull/126445
|
|
llvm-readobj print out symbol value name for xcoff symbol table.
reference doc:
https://www.ibm.com/docs/en/aix/7.2?topic=formats-xcoff-object-file-format#XCOFF__yaa3i18fjbau
|
|
RISCV Zicfilp/Zicfiss extensions uses the `.note.gnu.property` section
to store flags indicating the adoption of features based on these
extensions. This patch enables the llvm-readobj/llvm-readelf tools to
dump these flags with the `--note` flag.
|
|
Adds support to objdump and readobj for reading the `UOP_Epilog` entries
of Windows x64 unwind v2.
`UOP_Epilog` has a weird format:
The first `UOP_Epilog` in the unwind data is the "header":
* The least-significant bit of `OpInfo` is the "At End" flag, which
signifies that there is an epilog at the very end of the associated
function.
* `CodeOffset` is the length each epilog described by the current unwind
information (all epilogs have the same length).
Any subsequent `UOP_Epilog` represents another epilog for the current
function, where `OpInfo` and `CodeOffset` are combined to a 12-bit value
which is the offset of the beginning of the epilog from the end of the
current function. If the offset is 0, then this entry is actually
padding and can be ignored.
|
|
Apologies for the large change, I looked for ways to break this up and
all of the ones I saw added real complexity. This change focuses on the
option's prefixed names and the array of prefixes. These are present in
every option and the dominant source of dynamic relocations for PIE or
PIC users of LLVM and Clang tooling. In some cases, 100s or 1000s of
them for the Clang driver which has a huge number of options.
This PR addresses this by building a string table and a prefixes table
that can be referenced with indices rather than pointers that require
dynamic relocations. This removes almost 7k dynmaic relocations from the
`clang` binary, roughly 8% of the remaining dynmaic relocations outside
of vtables. For busy-boxing use cases where many different option tables
are linked into the same binary, the savings add up a bit more.
The string table is a straightforward mechanism, but the prefixes
required some subtlety. They are encoded in a Pascal-string fashion with
a size followed by a sequence of offsets. This works relatively well for
the small realistic prefixes arrays in use.
Lots of code has to change in order to land this though: both all the
option library code has to be updated to use the string table and
prefixes table, and all the users of the options library have to be
updated to correctly instantiate the objects.
Some follow-up patches in the works to provide an abstraction for this
style of code, and to start using the same technique for some of the
other strings here now that the infrastructure is in place.
|
|
The ARM Guarded Control Stack extension (GCS) is similar to existing
shadow stack extensions for other architectures.
The core note will include which features of GCS are enabled, which have
been locked in their current state, and the stack pointer of the shadow
stack.
Note that 0x40f is NT_ARM_POE, FPMR is supported by LLDB and GCS will be
soon, POE is not at this time. So NT_ARM_POE will be added when that
work starts.
See
https://github.com/torvalds/linux/blob/master/include/uapi/linux/elf.h.
|
|
This PR emits implements the ability to emit the PPC version for both
assembly and object files on AIX.
|
|
Mostly a stub, but adds some baseline tests and
tests for removed instructions.
|
|
This patch introduces a new generic target, `gfx9-4-generic`. Since it doesn’t support FP8 and XF32-related instructions, the patch includes several code reorganizations to accommodate these changes.
|
|
Heterogenous lookups allow us to call find with StringRef, avoiding a
temporary heap allocation of std::string.
|
|
|
|
|
|
Remove excess layer of indirection.
|
|
Remove unnecessary layer of indirection.
|
|
For llvm_linux platform, define the following meaning for bits 9, 10,
11:
- bit 9: set if indirect gotos signing is enabled;
- bit 10: set if type info vtable pointer discrimination is enabled;
- bit 11: set if function pointer type discrimination is enabled.
|
|
(#102843)
This allows us to use and print readable names in LLVM binary utilities.
|
