This PR adds basic support for the MIPS R5900 CPU, the Emotion Engine
processor used in the PlayStation 2.
**LLVM changes:**
- Add r5900 CPU definition (with soft float support for now)
- Disable instructions not supported by r5900 (64-bit multiply/divide,
LL/SC atomics, COP3)
- Add r5900 specific short loop delay slot fix (hardware errata
workaround)
- Set ISA extension `AFL_EXT_5900` in ELF flags for proper ABI
identification
**Clang changes:**
- Add r5900 as a valid CPU target for `-mcpu=r5900`
- Add r5900 to CPU test coverage
Use getRISCVVendorRelocationTypeName to resolve RISCV vendor-specific
relocation names (R_RISCV_CUSTOM192-255) when preceded by
R_RISCV_VENDOR.
This improves the output of llvm-readobj and llvm-objdump to show
vendor-specific names like R_RISCV_QC_ABS20_U, R_RISCV_QC_E_BRANCH
(QUALCOMM) and R_RISCV_NDS_BRANCH_10 (ANDES) instead of generic
R_RISCV_CUSTOM* names.
Per RISC-V psABI, R_RISCV_VENDOR must be placed immediately before its
associated vendor-specific relocation, so the vendor symbol is consumed
after one use. Unknown vendors fall back to R_RISCV_CUSTOM*.
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>
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>
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.
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.
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.
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).
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).
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.
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
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
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.
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 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.
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.
This contains the fpmr register which was added in Armv9.5-a. This
register mainly contains controls for fp8 formats.
It was added to the Linux Kernel in
4035c22ef7.
Treat 8th bit of version value for llvm_linux platform as signed GOT
flag.
- clang: define `PointerAuthELFGOT` LangOption and set 8th bit of
`aarch64-elf-pauthabi-version` LLVM module flag correspondingly;
- llvm-readobj: print `PointerAuthELFGOT` or `!PointerAuthELFGOT` in
version description of llvm_linux platform depending on whether the flag
is set.
If both `-fptrauth-init-fini` and `-fptrauth-calls` are passed, sign
function pointers in `llvm.global_ctors` and `llvm.global_dtors` with
constant discriminator 0xD9D4
(`ptrauth_string_discriminator("init_fini")`). Additionally, if
`-fptrauth-init-fini-address-discrimination` is passed, address
discrimination is used for signing (otherwise, just constant
discriminator is used).
For address discrimination, we use it's special form since uses of
`llvm.global_{c|d}tors` are disallowed (see
`Verifier::visitGlobalVariable`) and we can't emit `getelementptr`
expressions referencing these special arrays. A signed ctor/dtor pointer
with special address discrimination applied looks like the following:
```
ptr ptrauth (ptr @foo, i32 0, i64 55764, ptr inttoptr (i64 1 to ptr))
```
It turns out that the notes section for corefiles (or really any elf
file with multiple notes) is set up in such a way for LLVM formatted
output that the JSON equivalent only has the last note since the notes
are held in a dictionary with every key being Note. This pr alters the
layout for the notes to a list of dictionaries to sidestep this issue
for JSON output. Prior to this pr a note section in the output looked
like (for LLVM output):
```
Notes [
NoteSection {
Name: <?>
Offset: 0x2148
Size: 0x1F864
Note {
Owner: CORE
Data size: 0x150
Type: NT_PRSTATUS (prstatus structure)
Description data (
0000: 06000000 00000000 00000000 06000000 |................|
...
)
}
Note {
Owner: CORE
Data size: 0x88
Type: NT_PRPSINFO (prpsinfo structure)
Description data (
0000: 02440000 00000000 04054040 00000000 |.D........@@....|
....
```
But is now:
```
NoteSections [
NoteSection {
Name: <?>
Offset: 0x2148
Size: 0x1F864
Notes [
{
Owner: CORE
Data size: 0x150
Type: NT_PRSTATUS (prstatus structure)
Description data (
0000: 06000000 00000000 00000000 06000000 |................|
...
)
}
{
Owner: CORE
Data size: 0x88
Type: NT_PRPSINFO (prpsinfo structure)
Description data (
0000: 02440000 00000000 04054040 00000000 |.D........@@....|
...
```
