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........@@....|
...
```
CREL is a compact relocation format for the ELF object file format.
This patch adds integrated assembler support (using the RELA form)
available with `llvm-mc -filetype=obj -crel a.s -o a.o`.
A dependent patch will add `clang -c -Wa,--crel,--allow-experimental-crel`.
Also add llvm-readobj support (for both REL and RELA forms) to
facilitate testing the assembler. Additionally, yaml2obj gains support
for the RELA form to aid testing with llvm-readobj.
We temporarily assign the section type code 0x40000020 from the generic
range to `SHT_CREL`. We avoided using `SHT_LLVM_` or `SHT_GNU_` to
avoid code churn and maintain broader applicability for interested psABIs.
Similarly, `DT_CREL` is temporarily 0x40000026.
LLVM will change the code and break compatibility. This is not an issue
if all relocatable files using CREL are regenerated (aka no prebuilt
relocatable files).
Link: https://discourse.llvm.org/t/rfc-crel-a-compact-relocation-format-for-elf/77600
Pull Request: https://github.com/llvm/llvm-project/pull/91280
In the context of #95976 it became clear that the output for readobj
implied multi valued entries in several cases in the elf headers that
the documentation only allowed for a single value. DT_NEEDED is the
example here where the value is an offset into the string table without
any sort of separator that could give you multiple entries. This patch
alters the LLVM output so that the single valued nature is emphasized.
For example the output was:
```
DynamicSection [ (35 entries)
Tag Type Name/Value
0x000000000000001D RUNPATH Library runpath: [$ORIGIN/../lib:]
0x0000000000000001 NEEDED Shared library: [libm.so.6]
0x0000000000000001 NEEDED Shared library: [libz.so.1]
0x0000000000000001 NEEDED Shared library: [libzstd.so.1]
```
and is now
```
Tag Type Name/Value
0x000000000000001D RUNPATH Library runpath: [$ORIGIN/../lib:]
0x0000000000000001 NEEDED Shared library: libm.so.6
0x0000000000000001 NEEDED Shared library: libz.so.1
0x0000000000000001 NEEDED Shared library: libzstd.so.1
```
This pr also tests that multi-valued rpaths are handled correctly in the
JSON case (i.e. they become proper lists) like:
```
{
"Tag": 15,
"Type": "RPATH",
"Value": 9,
"Path": [
"x",
"w",
"U"
]
},
```
when separated by :
When printing JSON output with --dynamic-table I noticed that the output
is invalid JSON. This patch overrides the printDynamicTable() function
in the JSONELFDumper to return a list of dictionaries for the
DynamicSection value.
Before the output was:
```
{
"FileSummary": {
"File": "bin/llvm-readelf",
"Format": "elf64-x86-64",
"Arch": "x86_64",
"AddressSize": "64bit",
"LoadName": "<Not found>"
}DynamicSection [ (35 entries)
Tag Type Name/Value
0x000000000000001D RUNPATH Library runpath: [$ORIGIN/../lib:]
0x0000000000000001 NEEDED Shared library: [libm.so.6]
0x0000000000000001 NEEDED Shared library: [libz.so.1]
0x0000000000000001 NEEDED Shared library: [libzstd.so.1]
```
Now the output looks like:
```
"DynamicSection": [
{
"Tag": 29,
"Type": "RUNPATH",
"Value": 6322,
"Path": [
"$ORIGIN/../lib"
]
},
{
"Tag": 1,
"Type": "NEEDED",
"Value": 6109,
"Library": "libm.so.6"
},
```
This patch fixes an issue where, when printing corefile notes with
llvm-readobj as json, the dumper generated llvm formatted output which
isn't valid json. This alters the dumper to, in the NT_FILE, note, dump
properly formatted json data.
Prior to this patch the JSON output was formatted like:
```
"Mapping": [
"Start": 4096,
"End": 8192,
"Offset": 12288,
"Filename": "/path/to/a.out"
],
```
Whereas now it is formatted as:
```
"Mappings": [
{
"Start": 4096,
"End": 8192,
"Offset": 12288,
"Filename": "/path/to/a.out"
},
```
Which is valid. Additionally the LLVM output has changed to match the
structure of the JSON output (i.e. instead of lists of keys it is a list
of dictionaries)
https://reviews.llvm.org/D47919 dumped RELR relocations as
`R_*_RELATIVE` and added --raw-relr (not in GNU) for testing purposes
(more readable than `llvm-readelf -x .relr.dyn`). The option is obsolete
after `llvm-readelf -r` output gets improved (#89162).
Since --raw-relr never seems to get more adoption. Let's remove it to
avoid some complexity.
Pull Request: https://github.com/llvm/llvm-project/pull/89426
llvm-readelf/llvm-readobj print RELR as REL relocations with a fixed
type (e.g. `R_*_RELATIVE`). GNU readelf printed only addresses and have
recently switched to a more descritive style that includes a symbolic
address column (symbolized using .symtab/.strtab) (milestone: binutils
2.43).
This patch implements the new GNU style, which seems superior to the
current REL style and essentially obsoletes LLVM-specific --raw-relr
(`printRelrReloc`).
Pull Request: https://github.com/llvm/llvm-project/pull/89162
Reland #85231 after fixing build failure
https://lab.llvm.org/buildbot/#/builders/186/builds/15631.
Use `PRIx64` for format output of `uint64_t` as hex.
Original PR description below.
This adds support for `GNU_PROPERTY_AARCH64_FEATURE_PAUTH` feature (as
defined in https://github.com/ARM-software/abi-aa/pull/240) handling in
llvm-readobj and llvm-readelf. The following constants for supported
platforms are also introduced:
- `AARCH64_PAUTH_PLATFORM_INVALID = 0x0`
- `AARCH64_PAUTH_PLATFORM_BAREMETAL = 0x1`
- `AARCH64_PAUTH_PLATFORM_LLVM_LINUX = 0x10000002`
For the llvm_linux platform, output of the tools contains descriptions
of PAuth features which are enabled/disabled depending on the version
value. Version value bits correspond to the following `LangOptions`
defined in #85232:
- bit 0: `PointerAuthIntrinsics`;
- bit 1: `PointerAuthCalls`;
- bit 2: `PointerAuthReturns`;
- bit 3: `PointerAuthAuthTraps`;
- bit 4: `PointerAuthVTPtrAddressDiscrimination`;
- bit 5: `PointerAuthVTPtrTypeDiscrimination`;
- bit 6: `PointerAuthInitFini`.
Support for `.note.AARCH64-PAUTH-ABI-tag` is dropped since it's deleted
from the spec in ARM-software/abi-aa#250.
This adds support for `GNU_PROPERTY_AARCH64_FEATURE_PAUTH` feature (as
defined in https://github.com/ARM-software/abi-aa/pull/240) handling in
llvm-readobj and llvm-readelf. The following constants for supported
platforms are also introduced:
- `AARCH64_PAUTH_PLATFORM_INVALID = 0x0`
- `AARCH64_PAUTH_PLATFORM_BAREMETAL = 0x1`
- `AARCH64_PAUTH_PLATFORM_LLVM_LINUX = 0x10000002`
For the llvm_linux platform, output of the tools contains descriptions
of PAuth features which are enabled/disabled depending on the version
value. Version value bits correspond to the following `LangOptions`
defined in #85232:
- bit 0: `PointerAuthIntrinsics`;
- bit 1: `PointerAuthCalls`;
- bit 2: `PointerAuthReturns`;
- bit 3: `PointerAuthAuthTraps`;
- bit 4: `PointerAuthVTPtrAddressDiscrimination`;
- bit 5: `PointerAuthVTPtrTypeDiscrimination`;
- bit 6: `PointerAuthInitFini`.
Support for `.note.AARCH64-PAUTH-ABI-tag` is dropped since it's deleted
from the spec in ARM-software/abi-aa#250.
`TargetEndianness` is long and unwieldy. "Target" in the name is confusing. Rename it to "Endianness".
I cannot find noticeable out-of-tree users of `TargetEndianness`, but
keep `TargetEndianness` to make this patch safer. `TargetEndianness`
will be removed by a subsequent change.
Defines a subset of attributes and emits them to a section called
.hexagon.attributes.
The current attributes recorded are the attributes needed by
llvm-objdump to automatically determine target features and eliminate
the need to manually pass features.
Primary change is to add a flag `--pretty-pgo-analysis-map` to
llvm-readobj and llvm-objdump that prints block frequencies and branch
probabilities in the same manner as BFI and BPI respectively. This can
be helpful if you are manually inspecting the outputs from the tools.
In order to print, I moved the `printBlockFreqImpl` function from
Analysis to Support and renamed it to `printRelativeBlockFreq`.
Linux kernel fs/binfmt_elf_fdpic.c supports FDPIC for MMU-less systems.
GCC/binutils/qemu support FDPIC ABI for ARM
(https://github.com/mickael-guene/fdpic_doc).
_ARM FDPIC Toolchain and ABI_ provides a summary.
This patch implements FDPIC relocations to the integrated assembler.
There are 6 static relocations and 2 dynamic relocations, with
R_ARM_FUNCDESC as both static and dynamic.
gas requires `--fdpic` to assemble data relocations like `.word f(FUNCDESC)`.
This patch adds `MCTargetOptions::FDPIC` and reports an error if FDPIC
is not set.
Pull Request: https://github.com/llvm/llvm-project/pull/82187
