`MipsGOTParser` is a helper class that is used to dump MIPS GOT and PLT.
There is a problem with it: it might call report_fatal_error() on invalid input.
When this happens, the tool reports a crash:
```
# command stderr:
LLVM ERROR: Cannot find PLTGOT dynamic table tag.
PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backt
race.
Stack dump:
...
```
Such error were not tested. In this patch I've refactored `MipsGOTParser`:
I've splitted handling of GOT and PLT to separate methods. This allows to propagate
any possible errors to caller and should allow to dump the PLT when something is wrong
with the GOT and vise versa in the future.
I've added tests for each `report_fatal_error()`
and now calling the `reportError` instead. In the future we might want to switch to
reporting warnings, but it requres the additional testing and should
be performed independently.
I've kept `unwrapOrError` calls untouched for now as I'd like to focus on eliminating
`report_fatal_error` calls in this patch only.
Differential revision: https://reviews.llvm.org/D83225
Currently, llvm-readobj calls `report_fatal_error` when an object has
both REL and RELA dynamic relocations.
llvm-readelf is able to handle this case properly. This patch adds such a test case
and adjusts the llvm-readobj code to follow (and be consistent with its own RELR and PLTREL cases).
Differential revision: https://reviews.llvm.org/D83232
It is possible to:
1) Avoid using the `unwrapOrError` calls and hence allow to continue dumping even when
something is not OK with one of SHT_LLVM_LINKER_OPTIONS sections.
2) replace `reportWarning` with `reportUniqueWarning` calls. In this method it is no-op,
because it is not possible to have a duplicated warnings anyways, but since we probably
want to switch to `reportUniqueWarning` globally, this is a good thing to do.
This patch addresses both these points.
Differential revision: https://reviews.llvm.org/D83131
This introduces `printHashTableSymbols` and
`printGNUHashTableSymbols` to split the `printHashSymbols`.
It makes the code more readable and consistent.
Differential revision: https://reviews.llvm.org/D83040
This is a followup for D83129.
It is possible to make `getStaticSymbolName` report warnings inside
and return the "<?>" on a error. This allows to encapsulate errors handling
and slightly simplifies the logic in callers code.
Differential revision: https://reviews.llvm.org/D83208
The code we have currently reports an error if something is not right with the
profile section. Instead we can report a warning and continue dumping when it is possible.
This patch does it.
Differential revision: https://reviews.llvm.org/D83129
We might crash when the dynamic symbols table is empty (or not found)
and --hash-symbols is requested. Both .hash and .gnu.hash logic is affected.
The patch fixes this issue.
Differential revision: https://reviews.llvm.org/D83037
This is a follow-up for D82955, which allows to continue dumping when a symbol table is broken.
When we are unable to get the string table and trying to print symbols,
the existent tool logic together with D82955 reports an error:
"st_name (0x??) is past the end of the string table of size 0x??"
Though, when there is no string table, this message becomes misleading and excessive.
It is easy to fix it though and that is what this patch does.
Differential revision: https://reviews.llvm.org/D83042
When the --symbols option/--dyn-symbols is given we might report an
error and exit when something goes not right. E.g. when the SHT_SYMTAB
section is broken. Though we could report a warning and try to continue
dumping instead in many cases.
This patch removes `unwrapOrErr` calls from the code involved in the
flow described.
Differential revision: https://reviews.llvm.org/D82955
When we deriving the number of symbols from the DT_HASH table, we can crash when
calculate the number of symbols in the symbol table when SHT_DYNSYM
has sh_entsize == 0.
The patch fixes the issue.
Differential revision: https://reviews.llvm.org/D82877
There is no reason to report an error in `printSectionHeaders()`, we can report
a warning and continue dumping. This is what the patch does.
Differential revision: https://reviews.llvm.org/D82462
Start using the `checkGNUHashTable` helper which was recently introduced to report
a proper warning when a GNU hash table goes past the end of the file.
Differential revision: https://reviews.llvm.org/D82449
We have a division by zero crash currently when
the sh_entzize of the dynamic symbol table is 0.
Differential revision: https://reviews.llvm.org/D82180
It is possible to trigger a crash when a dynamic symbol has a
broken (too large) st_name and the DT_STRSZ is also broken.
We have the following code in the `Elf_Sym_Impl<ELFT>::getName`:
```
template <class ELFT>
Expected<StringRef> Elf_Sym_Impl<ELFT>::getName(StringRef StrTab) const {
uint32_t Offset = this->st_name;
if (Offset >= StrTab.size())
return createStringError(object_error::parse_failed,
"st_name (0x%" PRIx32
") is past the end of the string table"
" of size 0x%zx",
Offset, StrTab.size());
...
```
The problem is that `StrTab` here is a `ELFDumper::DynamicStringTab` member
which is not validated properly on initialization. So it is possible to bypass the
`if` even when the `st_name` is huge.
This patch fixes the issue.
Differential revision: https://reviews.llvm.org/D82201
Similar to D81937, we might crash when printing a histogram for a GNU hash table
with a 'symndx' index that is larger than the number of dynamic symbols.
This patch adopts and reuses the `getGnuHashTableChains()` helper which performs
a validation of the table. As a side effect the warning reported for
the --gnu-hash-table was improved.
Also with this change we start to report a warning when the histogram is requested for
the GNU hash table, but the dynamic symbols table is empty (size == 0).
Differential revision: https://reviews.llvm.org/D82010
`Elf_GnuHash_Impl` has the following method:
```
ArrayRef<Elf_Word> values(unsigned DynamicSymCount) const {
return ArrayRef<Elf_Word>(buckets().end(), DynamicSymCount - symndx);
}
```
When DynamicSymCount is less than symndx we return an array with the huge broken size.
This patch fixes the issue and adds an assert. This assert helped to fix an issue
in one of the test cases.
Differential revision: https://reviews.llvm.org/D81937
`printGnuHashTable` contains the code to check the GNU hash table.
This patch splits it to `getGnuHashTableChains` helper
(and reorders slightly to reduce).
Differential revision: https://reviews.llvm.org/D81928
Previously we only printed a symbol value when it has a non-empty name
or non-zero value.
This patch changes the behavior. Now we only omit a symbols value when
a relocation does not reference a symbol (i.e. symbol index == 0).
Seems it is what GNU readelf does, looking on its output.
Differential revision: https://reviews.llvm.org/D81842
Currently, llvm-readelf crashes when there is a STT_SECTION symbol for the null section
and this symbol is used in a relocation.
Differential revision: https://reviews.llvm.org/D81840
We have unobvious issue in the condition that is used to check
that we do not read past the EOF.
The problem is that the result of "GnuHashTable->nbuckets * 4" expression is uint32.
Because of that it was still possible to overflow it and pass the check.
There was no such problem with the "GnuHashTable->maskwords * sizeof(typename ELFT::Off)"
condition, because of `sizeof` on the right (which gives 64-bits value on x64),
but I've added an explicit conversion to 64-bit value for `GnuHashTable->maskwords` too.
Differential revision: https://reviews.llvm.org/D81103
This flag (and the whole field DT_FLAGS_1) originated from Solaris. I intend to use it in an LLD patch D80872.
Reviewed By: jhenderson
Differential Revision: https://reviews.llvm.org/D80871
Partially reverts feee98645d.
Add explicit braces to a different place to fix
"error: add explicit braces to avoid dangling else [-Werror,-Wdangling-else]"
This improves the next points for broken hash tables:
1) Use reportUniqueWarning to prevent duplication when
--hash-table and --elf-hash-histogram are used together.
2) Dump nbuckets and nchain fields. It is often possible
to dump them even when the table itself goes past the EOF etc.
Differential revision: https://reviews.llvm.org/D80373
llvm-readelf might crash when the .gnu.hash table goes past the EOF.
This patch splits and updates the code of a helper function `checkGNUHashTable`,
which is similar to `checkHashTable` and fixes the issue.
Differential revision: https://reviews.llvm.org/D80215
Summary:
Define ELF binary code for VE and modify code where should use this new code.
Depends on D79544.
Reviewed By: jhenderson
Differential Revision: https://reviews.llvm.org/D79545
As was mentioned in review comments for D80204,
`printHashHistogram` has 2 lambdas that are probably too large
and deserves splitting into member functions.
This patch does it.
Differential revision: https://reviews.llvm.org/D80546
When the `--elf-hash-histogram` is used, the code first tries to build
a histogram for the .hash table and then for the .gnu.hash table.
The problem is that dumper might return early when unable or do not need to
build a histogram for the .hash.
This patch reorders the code slightly to fix the issue and adds a test case.
Differential revision: https://reviews.llvm.org/D80204
Previously, the option was only implemented for LLVM output. This fixes
https://bugs.llvm.org/show_bug.cgi?id=45695.
At the current time, GNU readelf does not support this option.
Consequently, this patch simply attempts to roughly follow the output
style for similar options like --syms/--notes etc, combined with
--string-dump output.
Reviewed by: MaskRay, grimar
Differential Revision: https://reviews.llvm.org/D79939
We might have a scenario where a the `GbuHashTable` variable correctly points
to a place inside the file (we validate this fact early in `parseDynamicTable`),
but nbuckets/maskwords fields are broken in the way the code tries
to read the data past the EOF. This patch fixes the issue.
Differential revision: https://reviews.llvm.org/D79853
This patch is a NFC refactoring.
Currently the logic is overcomplicated, contains dead conditions and is very hard to read.
This patch performs a very straightforward simplification. Probably it can be
simplified and improved more, but we need to land test cases documenting/testing
all the current functionality first.
Differential revision: https://reviews.llvm.org/D78709
We do not verify the p_offset of the PT_INTERP header and tool may
crash when a program interpreter name string goes past the end of the file.
Differential revision: https://reviews.llvm.org/D79013
There are cases when we either might print garbage or crash when
reading strings for dumping dynamic tags.
For example when a string table is not null-terminated or goes past the EOF.
This patch fixes issues mentioned.
Differential revision: https://reviews.llvm.org/D77216
Currently we have no dedicated warnings, but we return error message instead of a result.
It is generally not consistent with another warnings we have.
This change was suggested and discussed here:
https://reviews.llvm.org/D77216#1954873
This change refines error messages we report and also I had to update the API
to implement it.
Differential revision: https://reviews.llvm.org/D77399
We have scenarios when the logic of --elf-hash-histogram/--hash-symbols/--hash-table
options might crash when given a broken hash table.
This patch adds pre-checks for tables for these 3 options
and provides test cases.
Differential revision: https://reviews.llvm.org/D77147
Leverage ARM ELF build attribute section to create ELF attribute section
for RISC-V. Extract the common part of parsing logic for this section
into ELFAttributeParser.[cpp|h] and ELFAttributes.[cpp|h].
Differential Revision: https://reviews.llvm.org/D74023
The unique warning handler was previously a property of the dump style,
but it is commonly used in the dumper too. Since the two ELF output
styles have no impact on the way warnings are printed, this patch moves
the handler and related functions into the dumper class, instead of the
dump style class.
Reviewed by: MaskRay, grimar
Differential Revision: https://reviews.llvm.org/D76777
If the section headers have been removed by a tool such as llvm-objcopy
or llvm-strip, previously llvm-readobj/llvm-readelf would not dump the
dynamic symbols when --dyn-symbols was specified. However, the nchain
value of the DT_HASH data specifies the number of dynamic symbols, so if
it is present, we can use that. This patch implements this behaviour.
Fixes https://bugs.llvm.org/show_bug.cgi?id=45089.
Reviewed by: grimar, MaskRay
Differential Revision: https://reviews.llvm.org/D76352
Prior to this change, for non-relocatable objects llvm-readobj would
assume that all symbols that corresponded to a stack size section's
entries were in the section specified by the section's sh_link field.
In the presence of an output section description combining
SHF_LINK_ORDER sections linking different output sections, this cannot
be respected, since linker script section patterns are "by name" by
nature. Consequently, the sh_link value would not be correct for all
section entries.
This patch changes llvm-readobj to ignore the section of symbols in a
non-relocatable object.
Fixes https://bugs.llvm.org/show_bug.cgi?id=45228.
Reviewed by: grimar, MaskRay
Differential Revision: https://reviews.llvm.org/D76425
* Delete boilerplate
* Change functions to return `Error`
* Test parsing errors
* Update callers of ARMAttributeParser::parse() to check the `Error` return value.
Since this patch touches nearly everything in the file, I apply
http://llvm.org/docs/Proposals/VariableNames.html and change variable
names to lower case.
Reviewed By: compnerd
Differential Revision: https://reviews.llvm.org/D75015
This changes the output of `llvm-readelf -n` from:
```
Displaying notes found at file offset 0x<...> with length 0x<...>:
```
to:
```
Displaying notes found in: .note.foo
```
And similarly, adds a `Name:` field to the `llvm-readobj -n` output for notes.
This change not only increases GNU compatibility, it also makes it much easier to read notes. Note that we still fall back to printing the file offset/length in cases where we don't have a section name, such as when printing notes in program headers or printing notes in a partially stripped file (GNU readelf does the same).
Fixes llvm.org/PR41339.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D75647
There was a short discussion about this:
https://reviews.llvm.org/D73484#inline-676942
To summarize:
It is a bit unclear to me why the `DT_SYMENT` tag exist.
LLD has the code that does:
"addInt(DT_SYMENT, sizeof(Elf_Sym));" and I guess other linkers has the same logic.
It is unclear why it can be possible to have other values rather than values of
a size of platform symbol. Seems it is not possible, and atm for me it looks that
this tag should not be used. This patch starts reporting the warning when the
value it contains differs from a symbol size for a 32/64 bit platform for safety.
It keeps the rest of the logic we have unchanged. Before this patch we did not handle
the tag at all.
Differential review: https://reviews.llvm.org/D74479
The current code has following issues:
1) It has a duplicated logic part.
2) This logic relies on unwrapOrError calls, but if we want to convert
them to warnings, we will need to change all of them what is hard to do
because of the duplication.
In this patch I've created a new method that returns Expected<> what allows
now to catch all errors in a single place and remove the code duplication.
Note: this change is itself a refactor NFC. It does not change the current logic
anyhow. It prepares the code for the follow-up(s).
Differential revision: https://reviews.llvm.org/D74545
Currently when we dump dynamic relocation with use of
DT_RELA/DT_RELASZ/DT_RELAENT tags, we crash when a symbol index
is larger than the number of dynamic symbols or
when there is no dynamic symbol table.
This patch adds test cases and fixes the issues.
Differential revision: https://reviews.llvm.org/D73560
DynRegionInfo is a helper class used to create memory ranges.
It is used for many things and can report errors.
Errors reported currently do not provide a good diagnostic.
This patch fixes it and adds a test for each possible case.
Differential revision: https://reviews.llvm.org/D73484
The current implementation stops dumping in case of a single error
it handles, though we can continue dumping.
This patch refines it: it adds a few warnings and a few test cases.
Differential revision: https://reviews.llvm.org/D73269
This is how it should've been and brings it more in line with
std::string_view. There should be no functional change here.
This is mostly mechanical from a custom clang-tidy check, with a lot of
manual fixups. It uncovers a lot of minor inefficiencies.
This doesn't actually modify StringRef yet, I'll do that in a follow-up.
We have no good test for --needed-libs option.
The one we have as a part of Object/readobj-shared-object.test
is not complete.
In this patch I've did a minor NFC changes to the implementation and
added a test. This allowed to remove this piece from
Object/readobj-shared-object.test
Differential revision: https://reviews.llvm.org/D73174
We have a test/Object/no-section-header-string-table.test which checks
what happens when an object does not have a section header string table.
It does not check the full output though.
Currently our output is different from GNU readelf, because the latter prints
"<no-strings>" instead of a section name, while we print nothing.
This patch fixes this, adds a proper test case and removes the one from test/Object,
as it is not a right folder for llvm-readelf tests.
Differential revision: https://reviews.llvm.org/D73193
This change is similar to one made for llvm-objdump in D72838.
llvm-readelf/llvm-readobj tools do not align the "Name/Value" column properly.
This patch adds a logic to calculate the size of indentation on fly
to fix such issues.
Differential revision: https://reviews.llvm.org/D72843
This removes the `getTypeString` from readeobj source because it
almost duplicates the existent method: `ELFFile<ELFT>::getDynamicTagAsString`.
Side effect: now it prints "<unknown:>0xHEXVALUE" instead of "(unknown)" for unknown values.
llvm-readelf before this patch printed:
```
0x0000000012345678 (unknown) 0x8765432187654321
0x000000006abcdef0 (unknown) 0x9988776655443322
0x0000000076543210 (unknown) 0x5555666677778888
```
and now it prints:
```
0x0000000012345678 (<unknown:>0x12345678) 0x8765432187654321
0x000000006abcdef0 (<unknown:>0x6abcdef0) 0x9988776655443322
0x0000000076543210 (<unknown:>0x76543210) 0x5555666677778888
```
GNU reaedlf prints different thing:
```
0x0000000012345678 (<unknown>: 12345678) 0x8765432187654321
0x000000006abcdef0 (Operating System specific: 6abcdef0) 0x9988776655443322
0x0000000076543210 (Processor Specific: 76543210) 0x5555666677778888
```
I am not sure we want to follow GNU here. Even if we do, it should be separate
patch probably. The new output looks better and closer to GNU anyways,
and the code is a bit simpler.
Differential revision: https://reviews.llvm.org/D71835
This is a natural clean-up after D71462/D71464.
It allows to define known section letters used for GNU style
in one place.
Differential revision: https://reviews.llvm.org/D71591
GNU uses `l` for SHF_X86_64_LARGE and `y` for SHF_ARM_PURECODE.
Lets follow.
To do this I had to refactor and refine how we print the help flags description.
It was too generic and inconsistent with GNU readelf.
Differential revision: https://reviews.llvm.org/D71464
Our logic that dumped the flags was buggy.
For LLVM style it dumped SHF_MASKPROC/SHF_MASKOS named constants, though
they are not flags, but masks.
For GNU style it was just very inconsistent with GNU which has logic
that is not straightforward. Imagine we have sh_flags == 0x90000000.
SHF_EXCLUDE ("E") has a value of 0x80000000 and SHF_MASKPROC is 0xf0000000.
GNU readelf will not print "E" or "Ep" in this case, but will print just
"p". It only will print "E" when no other processor flag is set.
I had to investigate the GNU source to find the algorithm and now our logic should
match it.
Differential revision: https://reviews.llvm.org/D71462
I've noticed that when we have all regular flags set, we print "WAEXMSILoGTx"
instead of "WAXMSILOGTCE" printed by GNU readelf.
It happens because:
1) We print SHF_EXCLUDE at the wrong place.
2) We do not recognize SHF_COMPRESSED, we print "x" instead of "C".
3) We print "o" instead of "O" for SHF_OS_NONCONFORMING.
This patch fixes differences and adds test cases.
Differential revision: https://reviews.llvm.org/D71418
It is discussed here https://reviews.llvm.org/D71118#inline-643172
Currently when a version is empty, llvm-readelf prints:
"000: 0 (*local*) 2 (<corrupt>)"
But GNU readelf does not treat empty section as corrupt.
There is no sense in having empty versions anyways it seems, but
this change is for consistency with GNU.
Differential revision: https://reviews.llvm.org/D71243
I was investigating a change previously discussed that eliminates an excessive
empty lines from the output when we report warnings and errors
(https://reviews.llvm.org/D70826#inline-639055) and found
that we need this refactoring or alike to achieve that.
The problem is that some of our functions that finds symbol versions just
fail instead of returning errors or printing warnings. Another problem
is that they might print a warning on the same line with the regular output.
In this patch I've splitted getting of the version information and dumping of it
for GNU printVersionSymbolSection(). I had to change a few methods to return
Error or Expected<> to do that properly.
Differential revision: https://reviews.llvm.org/D71118
This introduce a new helper which is used to parse the SHT_GNU_versym section.
LLVM/GNU styles implementations now use it to share the logic.
Differential revision: https://reviews.llvm.org/D71054
The PT_GNU_PROPERTY is generated by a linker to describe the
.note.gnu.property section. The Linux kernel uses this program header to
locate the .note.gnu.property section.
It is described in "The Linux gABI extension"
Include support for llvm-readelf, llvm-readobj and the yaml reader and
writers.
Differential Revision: https://reviews.llvm.org/D70959
After changes introduced in D70495 and D70826 its now possible
to significantly simplify the code we have.
This also fixes an issue: previous code assumed that version strings
should always be read from the dynamic string table. While it is
normally true, the string table should be taken from the corresponding
sh_link field.
Differential revision: https://reviews.llvm.org/D70855
This is similar to D70495, but for SHT_GNU_verneed section.
It solves the same problems: different implementations, lack of error reporting
and no test coverage.
DIfferential revision: https://reviews.llvm.org/D70826
Elfxx_Verdef contains the following field:
vd_version
Version revision. This field shall be set to 1.
(https://refspecs.linuxfoundation.org/LSB_5.0.0/LSB-Core-generic/LSB-Core-generic/symversion.html)
Our code should check the struct version for correctness. This patch does that.
(This will help to simplify or eliminate ELFDumper<ELFT>::LoadVersionDefs() which
has it's own logic to parse version definitions for no reason. It checks the
struct version currently).
Differential revision: https://reviews.llvm.org/D70810
When we dump SHT_GNU_verdef section that has sh_link that references a non-existent section,
llvm-readobj reports a warning and continues dump, but llvm-readelf fails with a error.
This patch fixes the issue and opens road for futher follow-ups for
improving the printGNUVersionSectionProlog().
Differential revision: https://reviews.llvm.org/D70776
This is a follow-up discussed in D70495 thread.
The current logic is unusual for llvm-readobj. It doesn't print predecessors
list when it is empty. This is not good for machine parsers.
D70495 had to add this condition during refactoring to reduce amount of changes,
in tests, because the original code also had a similar logic.
Now seems it is time to get rid of it. This patch does it.
Differential revision: https://reviews.llvm.org/D70717
Currently we have following issues:
1) We have 2 different implementations with a different behaviors for GNU/LLVM styles.
2) Errors are either not handled at all or we call report_fatal_error with not helpfull messages.
3) There is no test coverage even for those errors that are reported.
This patch reimplements parsing of the SHT_GNU_verdef section entries
in a single place, adds a few error messages and test coverage.
Differential revision: https://reviews.llvm.org/D70495
I've added a few tests that shows how the current code could overrun the section data
buffer while dumping. I had to rewrite the code to fix this.
Differential revision: https://reviews.llvm.org/D70112
Our elf-versioninfo.test is not perfect. It does not properly test how
flags are dumped and also we have a bug: they are dumped as enums in
LLVM style now, i.e not dumped properly.
GNU style uses a `versionFlagToString` method to build a string from flags
which seems is consistent with GNU readelf.
In this patch I fixed the issues mentioned.
Differential revision: https://reviews.llvm.org/D70399
Also only print each such warning once.
LLVM-style output will now print "<?>" for sections it cannot identify,
e.g. because the section index is invalid. GNU output continues to print
the raw index. In both cases where the st_shndx value is SHN_XINDEX and
the index cannot be looked up in the SHT_SYMTAB_SHNDX section (e.g.
because it is missing), the symbol is printed like other symbols with
st_shndx >= SHN_LORESERVE.
Reviewed by: grimar, MaskRay
Differential Revision: https://reviews.llvm.org/D69671
getSectionIndexName was trying to fetch two things at once, which led to
a somewhat tricky to understand interface involving passing output
parameters in, and also made it hard to return Errors further up the
stack.
This change is in preparation for changing the error handling.
Additionally, update a related test now that yaml2obj supports
SHT_SYMTAB_SHNDX properly (see d3963051c4), and add missing LLVM-style
coverage for symbols with shndx SHN_XINDEX. This test (after fixing)
caught a mistake in my first attempt at this patch, hence I'm including
it as part of this patch.
Reviewed by: grimar, MaskRay
Differential Revision: https://reviews.llvm.org/D69670
This updates the elf-invalid-versioning.test test case:
makes a cleanup, adds llvm-readobj calls and fixes 2
crash/assert issues I've found (test cases are provided).
Differential revision: https://reviews.llvm.org/D68705
It returns just a section_iterator currently and have a report_fatal_error call inside.
This change adds a way to return errors and handle them on caller sides.
The patch also changes/improves current users and adds test cases.
Differential revision: https://reviews.llvm.org/D69167
llvm-svn: 375408
This removes a few fields that are not useful:
"Section Name", "Address", "Offset" and "Link"
(they duplicated the information available under
the "Sections [" tag).
Differential revision: https://reviews.llvm.org/D68704
llvm-svn: 374541
This is similar to D68086.
We are entering an infinite loop when dumping a histogram for a specially crafted
.hash section with a loop in a chain.
Differential revision: https://reviews.llvm.org/D68771
llvm-svn: 374344
This patch:
* Adds a llvm-readobj/llvm-readelf test file for SHT_LLVM_ADDRSIG sections. (we do not have any)
* Enables dumping of SHT_LLVM_ADDRSIG with --all.
* Changes the logic to report a warning instead of an error when something goes wrong during dumping
(allows to continue dumping SHT_LLVM_ADDRSIG and other sections on error).
* Refactors a piece of logic to a new toULEB128Array helper which might be used for GNU-style
dumping implementation.
Differential revision: https://reviews.llvm.org/D68383
llvm-svn: 373890
In this patch `llvm-readobj` prints ASEs flags on a single line
separated by a comma. GNU `readelf` prints each ASEs flag on
a separate line. It will be fixed later.
llvm-svn: 373732
Initially llvm-readobj supports multiple command line options like
`--arm-attributes` and `--mips-plt-got` for display ELF arch-specific
information. Now all these options are superseded by the
`--arch-specific` one. It makes sense to have a single `printArchSpecificInfo`
method in the base `ObjDumper`, and hide all ELF/target specific details
in the `ELFDumper::printArchSpecificInfo` override.
Differential Revision: https://reviews.llvm.org/D68385
llvm-svn: 373731
It is possible to craft a .hash section that triggers an infinite loop
in llvm-readelf code. This patch fixes the issue and introduces
a warning.
Differential revision: https://reviews.llvm.org/D68086
llvm-svn: 373476
I started this patch as a refactoring, tried to make a helper for
getting symbol names, similar to how we get section names
used in warning messages.
So this patch cleanups the code and fixes an issue: symbol names
in warning messages were not demangled.
Differential revision: https://reviews.llvm.org/D68012
llvm-svn: 372867
The crash might happen when we have either a broken or unsupported object
and trying to resolve relocations when dumping the .stack_sizes section.
For the test case I used a 32-bits ELF header and a 64-bit relocation.
In this case a null pointer is returned by the code instead of the relocation
resolver function and then we crash.
Differential revision: https://reviews.llvm.org/D67962
llvm-svn: 372838
llvm-readobj currently handles .stack_sizes.* (e.g. .stack_sizes.foo)
as a normal stack sizes section. Though MC does not produce sections with
such names. Also, linkers do not combine .stack_sizes.* into .stack_sizes.
A mini discussion about this correctness issue is here: https://reviews.llvm.org/D67757#inline-609274
This patch changes implementation so that only now only '.stack_sizes' name is
accepted as a real stack sizes section.
Differential revision: https://reviews.llvm.org/D67824
llvm-svn: 372578
Georgii Rymar