Summary:
This did not need a separate struct because it is not past the
"architecture specific" ones in the identifier. This was accidentally
left when it was added somewhere else and caused unused variable
warnings.
Summary:
This patch fixes up the `makeTriple()` interface to emit append the
operating system information when it is readily avaialble from the ELF.
The main motivation for this is so the GPU architectures can be easily
identified correctly when given and ELF. E.g. we want
`amdgpu-amd-amdhsa` as the output and not `amdgpu--`.
This required adding support for the CUDA OS/ABI, which is easily found
to be `0x33` when using `readelf`.
Summary:
Currently, we don't emit any of the AMDGPU specific flags and options
when printing in GNU-mode (the default). This patch adds extra code to
handle outputting these values to match the output from GNU's `readelf`
when used on an AMDGPU image.
Summary:
The architecture that the CUDA application was compiled for is stored in
the ELF flags. This patch just adds some simple enum values to indicate
this to the user in a readable way.
This patch replaces uses of StringRef::{starts,ends}with with
StringRef::{starts,ends}_with for consistency with
std::{string,string_view}::{starts,ends}_with in C++20.
I'm planning to deprecate and eventually remove
StringRef::{starts,ends}with.
llvm-readobj and llvm-objdump have inconsistent handling of display
lma for sections.
This patch tries to common code up and adapt the same approach for
both tools.
Should avoid issues on big-endian hosts.
Note that we use aligned types because primitive integers are also
aligned. If we don't use aligned types, `HSAILProperties` ends up being
11 bytes instead of 12 (1 byte padding at the end of the struct added by
the compiler).
Technically only the first type needs to be aligned, but I just used
aligned types everywhere to be consistent.
Fixes#65280
Note that llvm::support::endianness has been renamed to
llvm::endianness while becoming an enum class as opposed to an
enum. This patch replaces support::{big,little,native} with
llvm::endianness::{big,little,native}.
Now that llvm::support::endianness has been renamed to
llvm::endianness, we can use the shorter form. This patch replaces
support::endianness with llvm::endianness.
GNU readelf introduced --extra-sym-info/-X to display the section name
for --syms (https://sourceware.org/PR30684). Port the feature, which is
currently llvm-readelf only.
For STO_AARCH64_VARIANT_PCS/STO_RISCV_VARIANT_PCS, the Ndx and Name
columns may not be aligned.
For a relocation, we don't differentiate the two cases:
* the symbol index is 0
* the symbol index is non zero, the type is not STT_SECTION, and the name is empty. Clang generates such local symbols for RISC-V linker relaxation.
So we may print
```
Offset Info Type Symbol's Value Symbol's Name + Addend
000000000000001c 0000000100000039 R_RISCV_32_PCREL 0000000000000000 0
// llvm-readobj
0x1C R_RISCV_32_PCREL - 0x0
```
while GNU readelf prints "<null>", which is clearer. Let's match the GNU behavior.
Related to https://reviews.llvm.org/D81842
```
000000000000001c 0000000100000039 R_RISCV_32_PCREL 0000000000000000 <null> + 0
// llvm-readobj
0x1C R_RISCV_32_PCREL <null> 0x0
```
Reviewed By: jhenderson, kito-cheng
Differential Revision: https://reviews.llvm.org/D155353
As suggested by @erichkeane in
https://reviews.llvm.org/D141451#inline-1429549
There's potential for a lot more cleanups around these APIs. This is
just a start.
Callers need to be more careful about sub-expressions producing strings
that don't outlast the expression using `llvm::demangle`. Add a
release note.
Differential Revision: https://reviews.llvm.org/D149104
This information helps to avoid considering cloning for blocks with indirect branches.
Reviewed By: jhenderson
Differential Revision: https://reviews.llvm.org/D150611
The generic ABI says:
> Padding is present, if necessary, to ensure 8 or 4-byte alignment for the next note entry (depending on whether the file is a 64-bit or 32-bit object). Such padding is not included in descsz.
Our parsing code currently aligns n_namesz. Fix the bug by aligning the start
offset of the descriptor instead. This issue has been benign because the primary
uses of sh_addralign=8 notes are `.note.gnu.property`, where
`sizeof(Elf_Nhdr) + sizeof("GNU") = 16` (already aligned by 8).
In practice, many 64-bit systems incorrectly use sh_addralign=4 notes.
We can use sh_addralign (= p_align) to decide the descriptor padding.
Treat an alignment of 0 and 1 as 4. This approach matches modern GNU readelf
(since 2018).
We have a few tests incorrectly using sh_addralign=0. We may make our behavior
stricter after fixing these tests.
Linux kernel dumped core files use `p_align=0` notes, so we need to support the
case for compatibility.
Reviewed By: jhenderson
Differential Revision: https://reviews.llvm.org/D150022
Small split change from D146023.
Migrate elf-notes to v4 and fix llvm-readobj to work with PAL metadata.
Reviewed By: kzhuravl
Differential Revision: https://reviews.llvm.org/D146119
This reverts commit c117c2c8ba.
itaniumDemangle calls std::strlen with the results of
std::string_view::data() which may not be NUL-terminated. This causes
lld/test/wasm/why-extract.s to fail when "expensive checks" are enabled
via -DLLVM_ENABLE_EXPENSIVE_CHECKS=ON. See D149675 for further
discussion. Back this out until the individual demanglers are converted
to use std::string_view.
As suggested by @erichkeane in
https://reviews.llvm.org/D141451#inline-1429549
There's potential for a lot more cleanups around these APIs. This is
just a start.
Callers need to be more careful about sub-expressions producing strings
that don't outlast the expression using ``llvm::demangle``. Add a
release note.
Reviewed By: MaskRay, #lld-macho
Differential Revision: https://reviews.llvm.org/D149104
These are used to store new state added by the Scalable Matrix
Extension which is documented in
https://developer.arm.com/documentation/ddi0616/aa/.
The values match those defined by Linux, see:
e62252bc55/include/uapi/linux/elf.h (L435)
The ZT register(s) are added by SME2 which is not yet publicly
documented but has support in LLVM and Linux already.
Also added descriptions for SVE and PAC_MASK notes since those
were missing.
Reviewed By: jhenderson
Differential Revision: https://reviews.llvm.org/D148126
This attempts to address an issue with overload resolution for `PrintNumber`
with `size_t` parameters on Darwin, brought up in
https://reviews.llvm.org/D146492.
On Aarch64 Darwin, `uint64_t` has a different typedef than `size_t`
(e.g., `unsigned long long` vs. `unsigned long`), whereas on Linux and
Windows they are the same.
This commit also reverts the static_cast's added in
064e2497e2, since they are no longer
needed.
Reviewed By: jhenderson
Differential Revision: https://reviews.llvm.org/D146771
Previously, the GNUELFDumper was the only implementer for Hash Histograms.
This patch moves the implementation for printHashHistogram and
printGnuHashHistogram into the ELFDumper base class, and allows each
derived class to specialize how it outputs that information.
This change also prevents the JSONELFDumper from emitting invalid JSON,
since the shared implementation in LLVMELFDumper no longer emits a
warning message to the output stream.
Reviewed By: jhenderson
Differential Revision: https://reviews.llvm.org/D137096
The current implementation output the LLVM formatted heading for group
sections, which was not valid JSON. This patch provides two small
customization points that allow the heading to vary between the two
implementations, and another that allows the section members to be
output as valid JSON objects.
Reviewed By: jhenderson
Differential Revision: https://reviews.llvm.org/D137095
Prior to this patch, the JSON output would emit an invalid key from the
shared LLVM implementation. This caused llvm-readobj to output invalid
JSON. This patch introduces a small helper function to print the
relocation information differently between the LLVM and JSON formats.
Before this patch:
```
"Relocations": [Section (2) .rel.text {
{
"Relocation": {
"Offset": 0,
"Type": {
"Value": "R_X86_64_NONE",
"RawValue": 0
},
"Symbol": {
"Value": "rel_0",
"RawValue": 1
}
}
},
...
```
After this patch:
```
"Relocations": [
{
"SectionIdx": 2,
"Relocs": [
{
"Relocation": {
"Offset": 0,
"Type": {
"Name": "R_X86_64_NONE",
"Value": 0
},
"Symbol": {
"Name": "rel_0",
"Value": 1
}
}
},
...
```
Reviewed By: jhenderson
Differential Revision: https://reviews.llvm.org/D137094
The existing JSON incorrectly outputs line breaks and other invalid JSON.
Example Before this patch:
```
...
"Relocations":[Section (9) .rela.dyn {
0xA3B0 R_X86_64_RELATIVE - 0x43D0
0xA3B8 R_X86_64_RELATIVE - 0x4A30
...
```
Example After this patch:
```
...
"Relocations":[Section (9) .rela.dyn {
{"Relocation":{"Offset":41904,"Type":{"Value":"R_X86_64_RELATIVE","RawValue":8},
"Symbol":{"Value":"","RawValue":0},"Addend":17360}},
{"Relocation":{"Offset":41912,"Type":{"Value":"R_X86_64_RELATIVE","RawValue":8},
"Symbol":{"Value":"","RawValue":0},"Addend":18992}},
{"Relocation":{"Offset":41920,"Type":{"Value":"R_X86_64_RELATIVE","RawValue":8},
"Symbol":{"Value":"","RawValue":0},"Addend":17440}},
...
```
Note there are still issues with the Section, but each Relocation is
now a valid JSON object that can be parsed. Future patches will address
the issues regarding JSON output for the Section.
Reviewed By: jhenderson
Differential Revision: https://reviews.llvm.org/D137089
Today, the LLVM output uses special handling when the Other field is 0.
This output makes sense for a command line utility that a human will
read, but JSON is a machine readable format, so being consistent is more
important. Prior to this change, any consumer of the JSON output would
need to handle the Other field specially, since the structure of the
JSON would no longer be consistent.
Changes to JSON output when Other flag == 0:
```
"Other": 0, -> "Other": {
"RawFlags": 0,
"Flags": []
},
```
There are no changes to when Other flag != 0:
```
"Other": { -> "Other": {
"RawFlags": 1, "RawFlags": 1,
"Flags": [ "Flags": [
... ...
] ]
}, },
```
This patch adds a overload for the JSONELFDumper's printSymbol() method,
that uses consistent output formatting, regardless of the value of the
Other field.
Depends on D137092
Reviewed By: jhenderson
Differential Revision: https://reviews.llvm.org/D137088
Since all ELFDumper implementations will require the same logic when
dealing with Other Flags, we move the logic into a helper so that it can
be easily reused across implementations.
Reviewed By: jhenderson
Differential Revision: https://reviews.llvm.org/D137092
