This also teaches MachO writers/readers about the MachO cpu subtype,
beyond the minimal subtype reader support present at the moment.
This also defines a preprocessor macro to allow users to distinguish
__arm64__ from __arm64e__.
arm64e defaults to an "apple-a12" CPU, which supports v8.3a, allowing
pointer-authentication codegen.
It also currently defaults to ios14 and macos11.
Differential Revision: https://reviews.llvm.org/D87095
This implementation of `ELFDumper<ELFT>::printAttributes()` in llvm-readobj has issues:
1) It crashes when the content of the attribute section is empty.
2) It uses `unwrapOrError` and `reportWarning` calls, though
ideally we want to use `reportUniqueWarning`.
3) It contains a TODO about redundant format version check.
`lib/Support/ELFAttributeParser.cpp` uses a hardcoded constant instead of the named constant.
This patch fixes all these issues.
Differential revision: https://reviews.llvm.org/D92318
This:
1) Changes `reportWarning` to `reportUniqueWarning` (no-op here).
2) Adds more context to the message.
3) Merges `broken-dynsym-link.test` into `dyn-symbols.test`, adds more testing.
Differential revision: https://reviews.llvm.org/D92380
This merges `invalid-attr-section-size.test` and `invalid-attr-version.test`
into `invalid-attributes-sec.test`.
This allows to have a single place where other related test cases can be added.
Differential revision: https://reviews.llvm.org/D92316
This is related to MIPS. Currently we might report an error and exit,
though there is no problem to report a warning and try to continue dumping
an object. The code uses `MipsGOTParser<ELFT> Parser`, which is isolated
in this method.
Differential revision: https://reviews.llvm.org/D92090
This starts using `reportUniqueWarnings` instead of `reportError`
in the code that is responsible for dumping notes.
Differential revision: https://reviews.llvm.org/D92021
`notes_begin()` is used for iterating over notes. This API in some cases might print
section type and index. At the same time during iterating, the `Elf_Note_Iterator`
might omit it as it doesn't have this info.
Because of above we might have the redundant duplication of information in warnings:
(See D92021).
```
warning: '[[FILE]]': unable to read notes from the SHT_NOTE section with index 1: SHT_NOTE section [index 1] has invalid offset (0x40) or size (0xffff0000)
```
This change stops reporting section index/type in Object/ELF.h/notes_begin().
(FTR, this was introduced by me for llvm-readobj in D64470).
Instead we can describe sections/program headers on the caller side.
Differential revision: https://reviews.llvm.org/D92081
This:
1) Changes its signature.
2) Refines the name of local variable (`SymTabName`->`LinkedSecName`,
because SHT_GNU_verneed/SHT_GNU_verdef are linked with the string table, not with the symbol table).
3) Stops using the `unwrapOrError` inside.
Differential revision: https://reviews.llvm.org/D91964
This stops using `RelocationRef` API in the `printStackSize` method
and starts using the "regular" API that is used in almost all other places
in ELFDumper.cpp.
This is not only makes the code to be more consistent, but helps to diagnose
issues better, because the `ELFObjectFile` API, which is used
currently to implement stack sized dumping sometimes has a behavior
that just doesn't work well for broken inputs.
E.g see how it gets the `symbol_end` iterator. It will just not work
well for a case when the `sh_size` is broken.
```
template <class ELFT>
basic_symbol_iterator ELFObjectFile<ELFT>::symbol_end() const {
...
DataRefImpl Sym = toDRI(SymTab, SymTab->sh_size / sizeof(Elf_Sym));
return basic_symbol_iterator(SymbolRef(Sym, this));
}
```
Differential revision: https://reviews.llvm.org/D91624
D91867 introduced the `tryGetSectionName` helper.
But we have `getPrintableSectionName` member with the similar
behavior which we can reuse. This patch does it.
Differential revision: https://reviews.llvm.org/D91954
This test contains YAMLs that can be merged with use of macros.
This opens road for adding more test cases.
Differential revision: https://reviews.llvm.org/D91953
It is possible to trigger a crash/misbehavior when the st_name field of
the signature symbol goes past the end of the string table.
This patch fixes it.
Differential revision: https://reviews.llvm.org/D91943
It is possible to trigger reading past the EOF by breaking fields like
DT_PLTRELSZ, DT_RELSZ or DT_RELASZ
This patch adds a validation in `DynRegionInfo` helper class.
Differential revision: https://reviews.llvm.org/D91787
Our code that dumps groups has 3 noticeable issues:
1) It uses `unwrapOrError` in many places.
2) It doesn't allow reporting unique warnings, because the `getGroups` helper is not
a member of `DumpStyle<ELFT>`.
3) It might just crash. See the comment for `StrTableOrErr->data() + Sym.st_name` line.
In this patch I am starting addressing these points.
For start I've converted one of `unwrapOrError` calls to a unique warning.
Differential revision: https://reviews.llvm.org/D91798
Imagine we have a YAML declaration of few sections: `foo1`, `<unnamed 2>`, `foo3`, `foo4`.
To put them into segment we can do (1*):
```
Sections:
- Section: foo1
- Section: foo4
```
or we can use (2*):
```
Sections:
- Section: foo1
- Section: foo3
- Section: foo4
```
or (3*) :
```
Sections:
- Section: foo1
## "(index 2)" here is a name that we automatically created for a unnamed section.
- Section: (index 2)
- Section: foo3
- Section: foo4
```
It looks really confusing that we don't have to list all of sections.
At first I've tried to make this rule stricter and report an error when there is a gap
(i.e. when a section is included into segment, but not listed explicitly).
This did not work perfect, because such approach conflicts with unnamed sections/fills (see (3*)).
This patch drops "Sections" key and introduces 2 keys instead: `FirstSec` and `LastSec`.
Both are optional.
Differential revision: https://reviews.llvm.org/D90458
This is recommit for D90903 with fixes for BB:
1) Used std::move<> when returning Expected<> (http://lab.llvm.org:8011/#/builders/112/builds/913)
2) Fixed the name of temporarily file in the file-headers.test (http://lab.llvm.org:8011/#/builders/36/builds/1269)
(a local old temporarily file was used before)
For creating `ELFObjectFile` instances we have the factory method
`ELFObjectFile<ELFT>::create(MemoryBufferRef Object)`.
The problem of this method is that it scans the section header to locate some sections.
When a file is truncated or has broken fields in the ELF header, this approach does
not allow us to create the `ELFObjectFile` and dump the ELF header.
This is https://bugs.llvm.org/show_bug.cgi?id=40804
This patch suggests a solution - it allows to delay scaning sections in the
`ELFObjectFile<ELFT>::create`. It now allows user code to call an object
initialization (`initContent()`) later. With that it is possible,
for example, for dumpers just to dump the file header and exit.
By default initialization is still performed as before, what helps to keep
the logic of existent callers untouched.
I've experimented with different approaches when worked on this patch.
I think this approach is better than doing initialization of sections (i.e. scan of them)
on demand, because normally users of `ELFObjectFile` API expect to work with a valid object.
In most cases when a section header table can't be read (because of an error), we don't
have to continue to work with object. So we probably don't need to implement a more complex API.
Differential revision: https://reviews.llvm.org/D90903
For creating `ELFObjectFile` instances we have the factory method
`ELFObjectFile<ELFT>::create(MemoryBufferRef Object)`.
The problem of this method is that it scans the section header to locate some sections.
When a file is truncated or has broken fields in the ELF header, this approach does
not allow us to create the `ELFObjectFile` and dump the ELF header.
This is https://bugs.llvm.org/show_bug.cgi?id=40804
This patch suggests a solution - it allows to delay scaning sections in the
`ELFObjectFile<ELFT>::create`. It now allows user code to call an object
initialization (`initContent()`) later. With that it is possible,
for example, for dumpers just to dump the file header and exit.
By default initialization is still performed as before, what helps to keep
the logic of existent callers untouched.
I've experimented with different approaches when worked on this patch.
I think this approach is better than doing initialization of sections (i.e. scan of them)
on demand, because normally users of `ELFObjectFile` API expect to work with a valid object.
In most cases when a section header table can't be read (because of an error), we don't
have to continue to work with object. So we probably don't need to implement a more complex API.
Differential revision: https://reviews.llvm.org/D90903
This differentiates the Ryzen 4000/4300/4500/4700 series APUs that were
previously included in gfx909.
Differential Revision: https://reviews.llvm.org/D90419
Change-Id: Ia901a7157eb2f73ccd9f25dbacec38427312377d
Currently it is impossible to create an instance of ELFObjectFile when the
SHT_SYMTAB_SHNDX can't be read. We error out when fail to parse the
SHT_SYMTAB_SHNDX section in the factory method.
This change delays reading of the SHT_SYMTAB_SHNDX section entries,
with it llvm-readobj is now able to work with such inputs.
Differential revision: https://reviews.llvm.org/D89379
`Link` is not an optional field currently.
Because of this it is not convenient to write macros.
This makes it optional and fixes corresponding test cases.
Differential revision: https://reviews.llvm.org/D90390
This is to enable --allow-unused-duplicates=false. This prefix appears
to be outdated and intentionally unused.
Reviewed By: rupprecht
Differential Revision: https://reviews.llvm.org/D90427
There is a possible scenario when we crash when dumping dynamic relocations.
For that we should have no section headers (to take the number of synamic symbols from)
and a dynamic relocation that refers to a symbol with an index that is too large to be in a file.
The patch fixes it.
Differential revision: https://reviews.llvm.org/D90214
When `NoHeaders` is set, we still have following issues:
1) We emit the `.shstrtab` implicit section of size 1 (empty string table).
2) We still align the start of the section header table, what affects the output size.
3) We still write section header table bytes.
This patch fixes all of these issues.
Differential revision: https://reviews.llvm.org/D90295
--section-details/-t is a GNU readelf option that produce
an output that is an alternative to --sections.
Differential revision: https://reviews.llvm.org/D89304
The current situation/behavior is:
1) llvm-readelf doesn't need a string that is specified by `DT_SONAME`.
2) llvm-readobj/elf always tries to read it, even when there is no `DT_SONAME` tag.
3) Because of that both tools reports a warning for many our test cases.
This patch delays getting a SOName string and changes the behavior (llvm-readobj) to
only report a warning when there is a `DT_SONAME` and a string cab't be read.
Warning is not reported for llvm-readelf, as it never tries to dump it.
Differential revision: https://reviews.llvm.org/D89384
Adds more testing in basic-assembly.s and a new test tables.s.
Adds support to yaml reading and writing of tables as well.
Differential Revision: https://reviews.llvm.org/D88815
This diff is similar to what D71394 did for `llvm-objdump` -- it avoids
trying to look up a section name for STABS symbols, since some STABS
symbol types (like `N_OSO`) use the `n_sect` field to store other data
instead of a section index.
Differential Revision: https://reviews.llvm.org/D88468
Specification for `SHT_HASH` table says (https://refspecs.linuxbase.org/elf/gabi4+/ch5.dynamic.html#hash)
that it contains `Elf32_Word` entries for both `32/64` bit objects.
But there is a problem with `EM_S390` and `ELF::EM_ALPHA` platforms: they use 8-bytes entries.
(see the issue reported: https://bugs.llvm.org/show_bug.cgi?id=47681).
Currently we might infer the size of the dynamic symbols table from hash table,
but because of the issue mentioned, the calculation is wrong. And also we don't dump the hash table
properly.
I am not sure if we want to support 8-bytes entries as they violates specification and also the
`.hash` table is kind of deprecated by itself (the `.gnu.hash` table is used nowadays).
So, the solution this patch suggests is to ban using of the hash table on `EM_S390/EM_ALPHA` platforms.
Differential revision: https://reviews.llvm.org/D88817
At AMD, in an internal audit of our code, we found some corner cases
where we were not quite differentiating targets enough for some old
hardware. This commit is part of fixing that by adding three new
targets:
* The "Oland" and "Hainan" variants of gfx601 are now split out into
gfx602. LLPC (in the GPUOpen driver) and other front-ends could use
that to avoid using the shaderZExport workaround on gfx602.
* One variant of gfx703 is now split out into gfx705. LLPC and other
front-ends could use that to avoid using the
shaderSpiCsRegAllocFragmentation workaround on gfx705.
* The "TongaPro" variant of gfx802 is now split out into gfx805.
TongaPro has a faster 64-bit shift than its former friends in gfx802,
and a subtarget feature could be set up for that to take advantage of
it. This commit does not make that change; it just adds the target.
V2: Add clang changes. Put TargetParser list in order.
V3: AMDGCNGPUs table in TargetParser.cpp needs to be in GPUKind order,
so fix the GPUKind order.
Differential Revision: https://reviews.llvm.org/D88916
Change-Id: Ia901a7157eb2f73ccd9f25dbacec38427312377d
This removes the precompiled binary and rewrites test to use YAML.
After this change we'll have no more precompiled inputs in `llvm-readobj/ELF/Inputs`.
Differential revision: https://reviews.llvm.org/D89097
It fixes possible scenarios when we crash/assert with `--hash-symbols` when
dumping an invalid GNU hash table which has a broken value in the buckets array.
This fixes a crash reported in comments for
https://bugs.llvm.org/show_bug.cgi?id=47681
Differential revision: https://reviews.llvm.org/D88561
This makes tests stricter and adds cases to verify what
we do when:
1) there is no `DT_HASH` tag (but there is a `SHT_HASH` section in sections header)
2) the sh_entsize of the `SHT_HASH` section is not equal to 4.
Differential revision: https://reviews.llvm.org/D88812
We have `--addrsig` implemented for `llvm-readobj`.
Usually it is convenient to use a single tool for dumping,
so it seems we might want to implement `--addrsig` for `llvm-readelf` too.
I've selected a simple output format which is a bit similar to one,
used for dumping of the symbol table. It looks like:
```
Address-significant symbols section '.llvm_addrsig' contains 2 entries:
Num: Name
1: foo
2: bar
```
Differential revision: https://reviews.llvm.org/D88835
This removed 2 last precompiled binaries from the mips-got.test.
YAML descriptions are used instead.
Differential revision: https://reviews.llvm.org/D88565
This removes 4 input files (one source file and 3 precompiled binaries) from
`mips-got.test` (now YAMLs are used instead) and also makes the testing of
the GNU output a bit stricter (`--strict-whitespace --match-full-lines`).
Differential revision: https://reviews.llvm.org/D88488
This is the one more patch for https://bugs.llvm.org/show_bug.cgi?id=47581
It fixes how we print an information for the Generic model. With this patch
we are able to read values from `.ARM.extab` and dump proper personality routines names/addresses.
Differential revision: https://reviews.llvm.org/D88478
Georgii Rymar