Commit Graph

40 Commits

Author SHA1 Message Date
Martin Storsjö 70c4930637 [llvm-readobj] [ARMWinEH] Try to resolve label symbols into regular ones
Unwind info generated by MSVC tends to have relocations pointing at
static "label" symbols like "$LN4" instead of regular ones based on
the actual function's name. Try to resolve such symbols to a non-label
symbol if possible (ideally to an external symbol), to improve
the readability.

Differential Revision: https://reviews.llvm.org/D101567
2021-05-04 22:22:18 +03:00
Martin Storsjö 4750a8b1bc Reapply [llvm-readobj] [ARMWinEH] Fix handling of relocations and symbol offsets
When looking up data referenced from pdata/xdata structures, the
referenced data can be found in two different ways:
- For an unrelocated object file, it's located via a relocation
- For a relocated, linked image, the data is referenced with an
  (image relative) absolute address

For the latter case, the absolute address can optionally be
described with a symbol.

For the case of an object file, there's two offsets involved; one
immediate offset encoded in the data location that is modified by
the relocation, and a section offset in the symbol.

Previously, for the ExceptionRecord field, we printed the offset
from the symbol (only) but used the immediate offset ignoring
the symbol's address (using only the symbol's section) for printing
the exception data.

Add a helper method for doing the lookup and address calculation,
for simplifying the calling code and making all the cases consistent.

This addresses an existing FIXME comment, fixing printing of the
exception data for cases where relocations point at individual
symbols in the xdata section (which is what MSVC generates) instead of
all relocations pointing at the start of the xdata section (which is
what LLVM generates).

This also fixes printing of the function name for packed entries in
linked images.

Relanded with a format string fix in the formatSymbol function; one
can't use %X as format string for an uint64_t. That bug has been
present since this code was added in e6971cab30.

Differential Revision: https://reviews.llvm.org/D100305
2021-04-30 09:51:23 +03:00
Martin Storsjö 5bf2ef9d86 Revert "[llvm-readobj] [ARMWinEH] Fix handling of relocations and symbol offsets"
This reverts commit 3778924088.

The added test fails on at least one buildbot, by printing a reversed
combination, printing "func3_xdata +0x18 (0x8)" while it's supposed to
be "func3_xdata +0x8 (0x18)", see e.g.
https://lab.llvm.org/buildbot/#/builders/107/builds/7269. Currently
no idea how that could happen, but reverting until it can be figured
out.
2021-04-30 00:06:16 +03:00
Martin Storsjö 3778924088 [llvm-readobj] [ARMWinEH] Fix handling of relocations and symbol offsets
When looking up data referenced from pdata/xdata structures, the
referenced data can be found in two different ways:
- For an unrelocated object file, it's located via a relocation
- For a relocated, linked image, the data is referenced with an
  (image relative) absolute address

For the latter case, the absolute address can optionally be
described with a symbol.

For the case of an object file, there's two offsets involved; one
immediate offset encoded in the data location that is modified by
the relocation, and a section offset in the symbol.

Previously, for the ExceptionRecord field, we printed the offset
from the symbol (only) but used the immediate offset ignoring
the symbol's address (using only the symbol's section) for printing
the exception data.

Add a helper method for doing the lookup and address calculation,
for simplifying the calling code and making all the cases consistent.

This addresses an existing FIXME comment, fixing printing of the
exception data for cases where relocations point at individual
symbols in the xdata section (which is what MSVC generates) instead of
all relocations pointing at the start of the xdata section (which is
what LLVM generates).

This also fixes printing of the function name for packed entries in
linked images.

Differential Revision: https://reviews.llvm.org/D100305
2021-04-29 23:35:10 +03:00
Kazu Hirata 3a80088357 [readobj] Use ListSeparator (NFC) 2021-03-01 23:40:31 -08:00
Martin Storsjö 7a91dad9e5 [llvm-readobj] [ARMWinEH] Clearly print an invalid case of packed unwind info as such
As the actual windows unwinder doesn't support this case, don't
pretend that it is supported when dumping the generated unwind info
either, even if it would be possible to interpret it as something
sensible.

This should reduce the risk of us emitting such a case in code
(although it's unlikely as long as the unwind info is generated
through the SEH opcodes, as the opcodes can't describe this case).

Differential Revision: https://reviews.llvm.org/D91529
2021-01-08 10:04:44 +02:00
Martin Storsjö 7b416c5e36 [llvm-readobj] [ARMWinEH] Print ARM64 packed unwind info
In addition to printing the individual fields, synthesize and
print the corresponding prolog for the unwind info (in reverse
order, to match how it's printed for non-packed unwind info).

Differential Revision: https://reviews.llvm.org/D87370
2020-09-15 08:50:02 +03:00
Martin Storsjö 8060283ff8 [llvm-readobj] [ARMWinEH] Print set_fp/add_fp differently in epilogues
This matches how e.g. stp/ldp and other opcodes are printed differently
for epilogues.

Also add a missing --strict-whitespace in an existing test that
was added explicitly for testing vertical alignment, and change to
using temp files for the generated object files.

Differential Revision: https://reviews.llvm.org/D87363
2020-09-10 11:26:43 +03:00
Martin Storsjö f5e2ea9a43 [AArch64] Add asm directives for the remaining SEH unwind codes
Add support in llvm-readobj for displaying them and support in the
asm parsser, AArch64TargetStreamer and MCWin64EH for emitting them.

The directives for the remaining basic opcodes have names that
match the opcode in the documentation.

The directives for custom stack cases, that are named
MSFT_OP_TRAP_FRAME, MSFT_OP_MACHINE_FRAME, MSFT_OP_CONTEXT
and MSFT_OP_CLEAR_UNWOUND_TO_CALL, are given matching assembler
directive names that fit into the rest of the opcode naming;
.seh_trap_frame, .seh_context, .seh_clear_unwound_to_call

The opcode MSFT_OP_MACHINE_FRAME is mapped to the existing
opecode enum UOP_PushMachFrame that is used on x86_64, and also
uses the corresponding existing x86_64 directive name
.seh_pushframe.

Differential Revision: https://reviews.llvm.org/D86889
2020-09-03 11:12:01 +03:00
Georgii Rymar 3d90a61cf2 [llvm-readobj] - Remove Error.cpp,.h and drop dependencies in the code.
We have Error.cpp/.h which contains some code for working with error codes.
In fact we use Error/Expected<> almost everywhere already and we can get rid
of these files.

Note: a few places in the code used readobj specific error codes,
e.g. `return readobj_error::unknown_symbol`. But these codes are never really used,
i.e. the code checks the fact of a success/error call only.
So I've changes them to `return inconvertibleErrorCode()` for now.
It seems that these places probably should be converted to use `Error`/`Expected<>`.

Differential revision: https://reviews.llvm.org/D86772
2020-09-01 16:46:17 +03:00
Martin Storsjö db259fe38b [llvm-readobj] Fix arm64 unwind opcode disassembly printing
Add a missing minus, fix vertical alignment of instructions for one opcode.

Differential Revision: https://reviews.llvm.org/D86523
2020-08-26 09:38:11 +03:00
Martin Storsjö af39708c2d [llvm-readobj] Fix/improve printing WinEH unwind info for linked PE images
ARMWinEHPrinter was already designed to handle linked PE images
(since d2941b43f4), but resolving symbols didn't consistently
take the image base into account (as linked images seldom have a
symbol table, except for in MinGW setups).

Win64EHDumper wasn't really designed to handle linked images (it would
crash if executed on such a file), but a few concepts (getSymbol,
taking a virtual address instead of a relocation, and
getSectionContaining for finding the section containing a certain
virtual address) can be borrowed from ARMWinEHPrinter.

Adjust ARMWinEHPrinter to print the address of the exception handler
routine as a VA instead of an RVA, consistently with other addresses
in the same printout, and make Win64EHDumper print addresses similarly
for image cases.

Differential Revision: https://reviews.llvm.org/D71303
2019-12-11 10:20:34 +02:00
Yuanfang Chen e03663fbb8 [llvm-readobj] flush output before crash
Otherwise the output could be lost.

llvm-svn: 372372
2019-09-20 06:33:03 +00:00
George Rimar 9d5e8a476f [Object/COFF.h] - Stop returning std::error_code in a few methods. NFCI.
There are 4 methods that return std::error_code now,
though they do not have to because they are always succeed.
I refactored them.

This allows to simplify the code in tools a bit.

llvm-svn: 369263
2019-08-19 14:32:23 +00:00
Fangrui Song 8be28cdc52 [Object] Change getSectionName() to return Expected<StringRef>
Summary:
It currently receives an output parameter and returns
std::error_code. Expected<StringRef> fits for this purpose perfectly.

Differential Revision: https://reviews.llvm.org/D61421

llvm-svn: 359774
2019-05-02 10:32:03 +00:00
Chandler Carruth 2946cd7010 Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.

Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.

llvm-svn: 351636
2019-01-19 08:50:56 +00:00
Jonas Devlieghere 45eb84f340 [Support] Make error banner optional in logAllUnhandledErrors
In a lot of places an empty string was passed as the ErrorBanner to
logAllUnhandledErrors. This patch makes that argument optional to
simplify the call sites.

llvm-svn: 346604
2018-11-11 01:46:03 +00:00
Eli Friedman d2941b43f4 [AArch64] [Windows] Misc fixes for llvm-readobj -unwind.
Use getImageBase() helper to compute the image base. Fix various
offsets/addresses/masks so they're actually correct.

This allows decoding unwind info from DLLs, and unwind info from object
files containing multiple functions.

Differential Revision: https://reviews.llvm.org/D54015

llvm-svn: 346036
2018-11-02 19:59:08 +00:00
Sanjin Sijaric cd41638292 [ARM64][Windows] Add unwind support to llvm-readobj
This patch adds support for dumping the unwind info from ARM64 COFF object
files.

Differential Revision: https://reviews.llvm.org/D53264

llvm-svn: 345108
2018-10-24 00:03:34 +00:00
Eric Christopher dd4baff48d Typo fix: epilouge->epilogue. NFC.
llvm-svn: 328833
2018-03-29 21:59:04 +00:00
Kevin Enderby 931cb65df2 Thread Expected<...> up from libObject’s getSymbolAddress() for symbols to allow
a good error message to be produced.

This is nearly the last libObject interface that used ErrorOr and the last one
that appears in llvm/include/llvm/Object/MachO.h .  For Mach-O objects this is
just a clean up because it’s version of getSymbolAddress() can’t return an
error.

I will leave it to the experts on COFF and ELF to actually add meaning full
error messages in their tests if they wish.  And also leave it to these experts
to change the last two ErrorOr interfaces in llvm/include/llvm/Object/ObjectFile.h
for createCOFFObjectFile() and createELFObjectFile() if they wish.

Since there are no test cases for COFF and ELF error cases with respect to
getSymbolAddress() in the test suite this is no functional change (NFC).

llvm-svn: 273701
2016-06-24 18:24:42 +00:00
Kevin Enderby 7bd8d99497 Thread Expected<...> up from libObject’s getType() for symbols to allow llvm-objdump to produce a good error message.
Produce another specific error message for a malformed Mach-O file when a symbol’s
section index is more than the number of sections.  The existing test case in test/Object/macho-invalid.test
for macho-invalid-section-index-getSectionRawName now reports the error with the message indicating
that a symbol at a specific index has a bad section index and that bad section index value.

Again converting interfaces to Expected<> from ErrorOr<> does involve
touching a number of places. Where the existing code reported the error with a
string message or an error code it was converted to do the same.

Also there some were bugs in the existing code that did not deal with the
old ErrorOr<> return values.  So now with Expected<> since they must be
checked and the error handled, I added a TODO and a comment:
"// TODO: Actually report errors helpfully" and a call something like
consumeError(NameOrErr.takeError()) so the buggy code will not crash
since needed to deal with the Error.

llvm-svn: 268298
2016-05-02 20:28:12 +00:00
Kevin Enderby 81e8b7d949 Thread Expected<...> up from libObject’s getName() for symbols to allow llvm-objdump to produce a good error message.
Produce another specific error message for a malformed Mach-O file when a symbol’s
string index is past the end of the string table.  The existing test case in test/Object/macho-invalid.test
for macho-invalid-symbol-name-past-eof now reports the error with the message indicating
that a symbol at a specific index has a bad sting index and that bad string index value.
 
Again converting interfaces to Expected<> from ErrorOr<> does involve
touching a number of places. Where the existing code reported the error with a
string message or an error code it was converted to do the same.  There is some
code for this that could be factored into a routine but I would like to leave that for
the code owners post-commit to do as they want for handling an llvm::Error.  An
example of how this could be done is shown in the diff in
lib/ExecutionEngine/RuntimeDyld/RuntimeDyldImpl.h which had a Check() routine
already for std::error_code so I added one like it for llvm::Error .

Also there some were bugs in the existing code that did not deal with the
old ErrorOr<> return values.  So now with Expected<> since they must be
checked and the error handled, I added a TODO and a comment:
“// TODO: Actually report errors helpfully” and a call something like
consumeError(NameOrErr.takeError()) so the buggy code will not crash
since needed to deal with the Error.

Note there fixes needed to lld that goes along with this that I will commit right after this.
So expect lld not to built after this commit and before the next one.

llvm-svn: 266919
2016-04-20 21:24:34 +00:00
Kevin Enderby 5afbc1cda7 Fix a crash in running llvm-objdump -t with an invalid Mach-O file already
in the test suite. While this is not really an interesting tool and option to run
on a Mach-O file to show the symbol table in a generic libObject format
it shouldn’t crash.

The reason for the crash was in MachOObjectFile::getSymbolType() when it was
calling MachOObjectFile::getSymbolSection() without checking its return value
for the error case.

What makes this fix require a fair bit of diffs is that the method getSymbolType() is
in the class ObjectFile defined without an ErrorOr<> so I needed to add that all
the sub classes.  And all of the uses needed to be updated and the return value
needed to be checked for the error case.

The MachOObjectFile version of getSymbolType() “can” get an error in trying to
come up with the libObject’s internal SymbolRef::Type when the Mach-O symbol
symbol type is an N_SECT type because the code is trying to select from the
SymbolRef::ST_Data or SymbolRef::ST_Function values for the SymbolRef::Type.
And it needs the Mach-O section to use isData() and isBSS to determine if
it will return SymbolRef::ST_Data.

One other possible fix I considered is to simply return SymbolRef::ST_Other
when MachOObjectFile::getSymbolSection() returned an error.  But since in
the past when I did such changes that “ate an error in the libObject code” I
was asked instead to push the error out of the libObject code I chose not
to implement the fix this way.

As currently written both the COFF and ELF versions of getSymbolType()
can’t get an error.  But if isReservedSectionNumber() wanted to check for
the two known negative values rather than allowing all negative values or
the code wanted to add the same check as in getSymbolAddress() to use
getSection() and check for the error then these versions of getSymbolType()
could return errors.

At the end of the day the error printed now is the generic “Invalid data was
encountered while parsing the file” for object_error::parse_failed.  In the
future when we thread Lang’s new TypedError for recoverable error handling
though libObject this will improve.  And where the added // Diagnostic(…
comment is, it would be changed to produce and error message
like “bad section index (42) for symbol at index 8” for this case.

llvm-svn: 264187
2016-03-23 20:27:00 +00:00
Richard Trieu 7a08381403 Remove uses of builtin comma operator.
Cleanup for upcoming Clang warning -Wcomma.  No functionality change intended.

llvm-svn: 261270
2016-02-18 22:09:30 +00:00
Rafael Espindola 8bab889b0f Convert getSymbolSection to return an ErrorOr.
This function can actually fail since the symbol contains an index to the
section and that can be invalid.

llvm-svn: 244375
2015-08-07 23:27:14 +00:00
Rafael Espindola ed067c45d4 Return ErrorOr from getSymbolAddress.
It can fail trying to get the section on ELF and COFF. This makes sure the
error is handled.

llvm-svn: 241366
2015-07-03 18:19:00 +00:00
Rafael Espindola 5d0c2ffadf Return ErrorOr from SymbolRef::getName.
This function can really fail since the string table offset can be out of
bounds.

Using ErrorOr makes sure the error is checked.

Hopefully a lot of the boilerplate code in tools/* can go away once we have
a diagnostic manager in Object.

llvm-svn: 241297
2015-07-02 20:55:21 +00:00
Rafael Espindola 96d071cd0c Don't return error_code from function that never fails.
llvm-svn: 241021
2015-06-29 23:29:12 +00:00
Rafael Espindola 2fa80cc5fd Simplify getSymbolType.
This is still a really odd function. Most calls are in object format specific
contexts and should probably be replaced with a more direct query, but at least
now this is not too obnoxious to use.

llvm-svn: 240777
2015-06-26 12:18:49 +00:00
Chandler Carruth d9903888d9 [cleanup] Re-sort all the #include lines in LLVM using
utils/sort_includes.py.

I clearly haven't done this in a while, so more changed than usual. This
even uncovered a missing include from the InstrProf library that I've
added. No functionality changed here, just mechanical cleanup of the
include order.

llvm-svn: 225974
2015-01-14 11:23:27 +00:00
Rafael Espindola 802912743e Remove bogus std::error_code returns form SectionRef.
There are two methods in SectionRef that can fail:

* getName: The index into the string table can be invalid.
* getContents: The section might point to invalid contents.

Every other method will always succeed and returning and std::error_code just
complicates the code. For example, a section can have an invalid alignment,
but if we are able to get to the section structure at all and create a
SectionRef, we will always be able to read that invalid alignment.

llvm-svn: 219314
2014-10-08 15:28:58 +00:00
Rui Ueyama 062c406a85 Support: Delete {aligned_,}{u,}{little,big}8_t
The byte has no endianness, so these types don't make sense.
uint8_t should be used instead.

llvm-svn: 217631
2014-09-11 21:46:33 +00:00
Benjamin Kramer 0e18484696 Rephrase loop so it doesn't leave unused bools around in Release mode.
llvm-svn: 212102
2014-07-01 14:46:44 +00:00
Alp Toker e69170a110 Revert "Introduce a string_ostream string builder facilty"
Temporarily back out commits r211749, r211752 and r211754.

llvm-svn: 211814
2014-06-26 22:52:05 +00:00
Alp Toker 614717388c Introduce a string_ostream string builder facilty
string_ostream is a safe and efficient string builder that combines opaque
stack storage with a built-in ostream interface.

small_string_ostream<bytes> additionally permits an explicit stack storage size
other than the default 128 bytes to be provided. Beyond that, storage is
transferred to the heap.

This convenient class can be used in most places an
std::string+raw_string_ostream pair or SmallString<>+raw_svector_ostream pair
would previously have been used, in order to guarantee consistent access
without byte truncation.

The patch also converts much of LLVM to use the new facility. These changes
include several probable bug fixes for truncated output, a programming error
that's no longer possible with the new interface.

llvm-svn: 211749
2014-06-26 00:00:48 +00:00
Rafael Espindola bff5d0d16a Remove all uses of 'using std::error_code' from headers.
llvm-svn: 210866
2014-06-13 01:25:41 +00:00
Saleem Abdulrasool c86b54c86d tools: add a high level explanation for WoA EH data
Add a brief explanation of the data section layout for the unwind data that the
Windows on ARM EH models.  This is simply to provide a rough idea of the layout
of the code involved in the decoding of the unwinding.  Details on the involved
data structures are available in the associated support header.  The bulk of it
is related to printing out the byte-code to help validate generation of WoA EH.

No functional change.

llvm-svn: 210397
2014-06-07 19:23:07 +00:00
Saleem Abdulrasool 72e9a25c76 tools: fix parenthesis warning from GCC
Add parenthesis as suggested by GCC.

llvm-svn: 210194
2014-06-04 16:03:20 +00:00
Saleem Abdulrasool e6971cab30 tools: initial implementation of WoA EH decoding
Add support to llvm-readobj to decode Windows ARM Exception Handling data.  This
uses the previously added datastructures to decode the information into a format
that can be used by tests.  This is a necessary step to add support for emitting
Windows on ARM exception handling information.

A fair amount of formatting inspiration is drawn from the Win64 EH printer as
well as the ARM EHABI printer.  This allows for a reasonably thorough look into
the encoded data.

llvm-svn: 210192
2014-06-04 15:47:15 +00:00