This addresses post review comment for D92018.
The warning was:
```
error: loop variable 'Note' is always a copy because the range of type 'iterator_range<llvm::object::ELFFile<llvm::object::ELFType<llvm::support::big, true> >::Elf_Note_Iterator>' (aka 'iterator_range<Elf_Note_Iterator_Impl<ELFType<(llvm::support::endianness)0U, true> > >') does not return a reference [-Werror,-Wrange-loop-analysis]
for (const typename ELFT::Note &Note : Obj.notes(S, Err))
```
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
AVR and PPC64 bots reports link errors:
(http://lab.llvm.org:8011/#/builders/112/builds/1522)
(http://lab.llvm.org:8011/#/builders/52/builds/1764)
/tmp/cclOvLx0.s: Assembler messages:
/tmp/cclOvLx0.s:9223: Error: symbol `_ZN4llvm12function_refIFvvEE11callback_fnIUlvE2_EEvl' is already defined
/tmp/cclOvLx0.s:9227: Error: symbol `.L._ZN4llvm12function_refIFvvEE11callback_fnIUlvE2_EEvl' is already defined
/tmp/cclOvLx0.s:10272: Error: symbol `_ZN4llvm12function_refIFvvEE11callback_fnIUlvE2_EEvl' is already defined
/tmp/cclOvLx0.s:10276: Error: symbol `.L._ZN4llvm12function_refIFvvEE11callback_fnIUlvE2_EEvl' is already defined
/tmp/cclOvLx0.s:10285: Error: symbol `_ZN4llvm12function_refIFvvEE11callback_fnIUlvE2_EEvl' is already defined
/tmp/cclOvLx0.s:10289: Error: symbol `.L._ZN4llvm12function_refIFvvEE11callback_fnIUlvE2_EEvl' is already defined
/tmp/ccFJYr6I.s: Assembler messages:
/tmp/ccFJYr6I.s:6284: Error: symbol `_ZN4llvm12function_refIFvvEE11callback_fnIUlvE2_EEvl' is already defined
/tmp/ccFJYr6I.s:7053: Error: symbol `_ZN4llvm12function_refIFvvEE11callback_fnIUlvE2_EEvl' is already defined
/tmp/ccFJYr6I.s:7093: Error: symbol `_ZN4llvm12function_refIFvvEE11callback_fnIUlvE2_EEvl' is already defined
I *guess* the reason might be the default lambda argument. I've removed it.
We have a similar logic for LLVM/GNU styles that can be deduplicated.
This will allow to replace `reportError` calls with `reportUniqueWarning`
calls in a single place.
Differential revision: https://reviews.llvm.org/D92018
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
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
Our `printStackSize` implementation currently uses
API like `RelocationRef`, `object::symbol_iterator`.
It is not ideal as it doesn't allow
to handle possible error conditions properly.
Some time ago I started rewriting it and this NFC patch is
a one more step toward to it. Here I am introducing the
`forEachRelocationDo` helper. With it it is possible to iterate
over all kinds of relocations, what is helpful for improving
the code in `printStackSize` and around.
Differential revision: https://reviews.llvm.org/D91530
This allows to reuse the RelocationResolver from the code
that doesn't want to deal with `RelocationRef` class.
I am going to use it in llvm-readobj. See the description
of D91530 for more details.
Differential revision: https://reviews.llvm.org/D91533
This patch adds support for creating Guard Address-Taken IAT Entry Tables (.giats$y sections) in object files, matching the behavior of MSVC. These contain lists of address-taken imported functions, which are used by the linker to create the final GIATS table.
Additionally, if any DLLs are delay-loaded, the linker must look through the .giats tables and add the respective load thunks of address-taken imports to the GFIDS table, as these are also valid call targets.
Reviewed By: rnk
Differential Revision: https://reviews.llvm.org/D87544
No longer rely on an external tool to build the llvm component layout.
Instead, leverage the existing `add_llvm_componentlibrary` cmake function and
introduce `add_llvm_component_group` to accurately describe component behavior.
These function store extra properties in the created targets. These properties
are processed once all components are defined to resolve library dependencies
and produce the header expected by llvm-config.
Differential Revision: https://reviews.llvm.org/D90848
This broke both Firefox and Chromium (PR47905) due to what seems like dllimport
function not being handled correctly.
> This patch adds support for creating Guard Address-Taken IAT Entry Tables (.giats$y sections) in object files, matching the behavior of MSVC. These contain lists of address-taken imported functions, which are used by the linker to create the final GIATS table.
> Additionally, if any DLLs are delay-loaded, the linker must look through the .giats tables and add the respective load thunks of address-taken imports to the GFIDS table, as these are also valid call targets.
>
> Reviewed By: rnk
>
> Differential Revision: https://reviews.llvm.org/D87544
This reverts commit cfd8481da1adba1952e0f6ecd00440986e49a946.
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
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
--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
Format specifiers of incorrect length are replaced with format specifier
macros from `<cinttypes>` matching the typedefs used to declare the type
of the value being printed.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D89637
This patch adds support for creating Guard Address-Taken IAT Entry Tables (.giats$y sections) in object files, matching the behavior of MSVC. These contain lists of address-taken imported functions, which are used by the linker to create the final GIATS table.
Additionally, if any DLLs are delay-loaded, the linker must look through the .giats tables and add the respective load thunks of address-taken imports to the GFIDS table, as these are also valid call targets.
Reviewed By: rnk
Differential Revision: https://reviews.llvm.org/D87544
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
If the metadata is valid yaml, we can print it, even if it failed
validation. That makes it easier to debug any wrong metadata.
Differential Revision: https://reviews.llvm.org/D89243
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
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
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 patch adds support for creating Guard Address-Taken IAT Entry Tables (.giats$y sections) in object files, matching the behavior of MSVC. These contain lists of address-taken imported functions, which are used by the linker to create the final GIATS table.
Additionally, if any DLLs are delay-loaded, the linker must look through the .giats tables and add the respective load thunks of address-taken imports to the GFIDS table, as these are also valid call targets.
Reviewed By: rnk
Differential Revision: https://reviews.llvm.org/D87544
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
This is a part of https://bugs.llvm.org/show_bug.cgi?id=47581.
We have the following computation:
```
(1) uint64_t Location = Address & 0x7fffffff;
(2) if (Location & 0x04000000)
(3) Location |= (uint64_t) ~0x7fffffff;
(4) return Location + Place;
```
At line 2 there is a mistype. The constant should be `0x40000000`,
not `0x04000000`, because the intention here is to sign extend the `Location`,
which is the 31 bit signed value.
Differential revision: https://reviews.llvm.org/D88407
This is the first patch for https://bugs.llvm.org/show_bug.cgi?id=47581.
Currently -u does not compute function addresses correctly and
dumps broken addresses for non-relocatable objects.
ARM spec says:
"An index table entry consists of 2 words.
The first word contains a prel31 offset (see Relocations) to the start of a function, with bit 31 clear."
...
"The relocated 31 bits form a place-relative signed offset to the referenced entity.
For brevity, this document will refer to the results of these relocations as "prel31 offsets"."
(https://developer.arm.com/documentation/ihi0038/c/?lang=en#index-table-entries)
(https://developer.arm.com/documentation/ihi0038/c/?lang=en#relocations)
Currently we use an address of the SHT_ARM_EXIDX section instead of an address of an entry
in computations. As a result we compute an offset that is not really "place-relative",
but section relative, what is wrong.
The patch fixes this issue.
Differential revision: https://reviews.llvm.org/D88076
In a post review comments for D88097 it was mentioned that code
triggers bunch of warnings of the form:
llvm/tools/llvm-readobj/ELFDumper.cpp:5299:28: warning: loop variable 'Note' is always a copy because
the range of type 'iterator_range<llvm::object::ELFFile<llvm::object::ELFType<llvm::support::big, true> >::Elf_Note_Iterator>'
(aka 'iterator_range<Elf_Note_Iterator_Impl<ELFType<(llvm::support::endianness)0U, true> > >') does not return a reference [-Wrange-loop-analysis]
for (const Elf_Note &Note : this->Obj.notes(P, Err))
It happens because Elf_Note is always copied here:
Elf_Note_Impl<ELFT> operator*() const {
assert(Nhdr && "dereferenced ELF note end iterator");
return Elf_Note_Impl<ELFT>(*Nhdr);
}
This patch fixes the issue by removing a reference.
Recent refactoring introduced a symbol index argument for `getFullSymbolName` method,
which is only used for reporting error messages about invalid extended symbol indexes.
There are few issues in the implementation and we don't report correct symbol indices
when dumping MIPS GOT/PLT entries currently.
This patch adds test cases and fixes the issue.
Differential revision: https://reviews.llvm.org/D88089
Currently `--relocations` ignores section symbol names and always prints
section names for them. This is inconsistent with GNU readelf and with `--symbols`.
We have a code in `getFullSymbolName` (which is used for `--symbols`) which can be
reused for `getRelocationTarget` (used for `--relocations`).
With that the issue described is fixed and code becomes a bit shorter.
Also with this change we start to print more relocations (in situations when we just
showed warnings instead before) and also start to report more diagnostic warnings
(see reloc-zero-name-or-value.test).
Differential revision: https://reviews.llvm.org/D87613
This:
1) Replaces pointers with references in many places.
2) Adds few TODOs about fixing possible unhandled errors (in ARMEHABIPrinter.h).
3) Replaces `auto`s with actual types.
4) Removes excessive arguments.
5) Adds `const ELFFile<ELFT> &Obj;` member to `ELFDumper` to simplify the code.
Differential revision: https://reviews.llvm.org/D88097
We have an issue with `getFullSymbolName`: it assumes that the symbol passed is
always in the `.symtab`, what is wrong. We might calculate and report a wrong index currently.
I've added a test case revealing that.
This patch adds the "symbol index" argument to `getFullSymbolName` signature,
what fixes the issue.
Differential revision: https://reviews.llvm.org/D87899
We use `FirstSym` argument in `getExtendedSymbolTableIndex` to calculate
a symbol index:
```
&Sym - &FirstSym
```
Instead, we could pass the symbol index directly.
This is what this patch does, it allows to simplify another llvm-readobj API.
Differential revision: https://reviews.llvm.org/D88016
We have an issue with `ELFDumper<ELFT>::getSymbolSectionName`:
1) It is used deeply for both LLVM/GNU styles and might return LLVM-style only
values to describe symbols: "Undefined", "Processor Specific", "Absolute", etc.
2) `getSymbolSectionName` is used by `getFullSymbolName` and these special values
might appear instead of symbol names in many places.
This occurs for unnamed section symbols currently.
This patch extracts the LLVM specific logic to `LLVMStyle<ELFT>::printSymbolSection`,
which seems to be the only place where we want to print the special values mentioned.
It also adds a meaningful new warning that is reported when we are unable to get
a section index for a section symbol.
Differential revision: https://reviews.llvm.org/D87764
