Commit Graph

852 Commits

Author SHA1 Message Date
Reid Kleckner f27f3f8491 [Symbolize] Check if the PE file has a PDB and emit an error if we can't load it
Summary:
Previously we would try to load PDBs for every PE executable we tried to
symbolize. If that failed, we would fall back to DWARF. If there wasn't
any DWARF, we'd print mostly useless symbol information using the export
table.

With this change, we only try to load PDBs for executables that claim to
have them. If that fails, we can now print an error rather than falling
back silently. This should make it a lot easier to diagnose and fix
common symbolization issues, such as not having DIA or not having a PDB.

Reviewers: zturner, eugenis

Subscribers: llvm-commits

Differential Revision: http://reviews.llvm.org/D20982

llvm-svn: 271725
2016-06-03 20:25:09 +00:00
Reid Kleckner 2da433ea99 [COFF] Expose the PE debug data directory and dump it
This directory is used to find if there is a PDB associated with an
executable. I plan to use this functionality to teach llvm-symbolizer
whether it should use DIA or DWARF to symbolize a given DLL.

Reviewers: majnemer

Differential Revision: http://reviews.llvm.org/D20885

llvm-svn: 271539
2016-06-02 17:10:43 +00:00
Kevin Enderby 9acb109930 Change llvm-objdump, llvm-nm and llvm-size when reporting an object file error
when the object is from a slice of a Mach-O Universal Binary use something like
"foo.o (for architecture i386)" as part of the error message when expected.

Also fixed places in these tools that were ignoring object file errors from
MachOUniversalBinary::getAsObjectFile() when the code moved on to see if
the slice was an archive.

To do this MachOUniversalBinary::getAsObjectFile() and
MachOUniversalBinary::getObjectForArch() were changed from returning
ErrorOr<...> to Expected<...> then that was threaded up to its users.

Converting these interfaces to Expected<> from ErrorOr<> does involve
touching a number of places. To contain the changes for now the use of
errorToErrorCode() is still used in two places yet to be fully converted.

llvm-svn: 271332
2016-05-31 20:35:34 +00:00
David Majnemer e21296626c [Object] Return an error code instead of asserting
This makes it easier to report errors up the stack.

llvm-svn: 271140
2016-05-28 19:45:51 +00:00
Chris Bieneman 1bc0f4395c [CMake] Restrict libxar linkage to just llvm-objdump
At some point we're going to need libObject to have this dependency, but as it is now this is causing too many headaches. This commit will reduce the linkage to just llvm-objdump where it is strictly needed, and we'll cross the libObject bridge later when we need it.

llvm-svn: 270866
2016-05-26 16:32:40 +00:00
Peter Collingbourne 4718f8b5f1 Add FIXMEs to all derived classes of std::error_category.
This helps make clear that we're moving away from std::error_code.

Differential Revision: http://reviews.llvm.org/D20592

llvm-svn: 270604
2016-05-24 20:13:46 +00:00
George Rimar 401e4e570e Recommit r270547 ([llvm-dwarfdump] - Teach dwarfdump to decompress debug sections in zlib style.)
Fix was:
1) Had to regenerate dwarfdump-test-zlib.elf-x86-64, dwarfdump-test-zlib-gnu.elf-x86-64
(because llvm-symbolizer-zlib.test uses that inputs for its purposes and failed).
2) Updated llvm-symbolizer-zlib.test (updated used call function address to match new files + 
added one more check for newly created dwarfdump-test-zlib-gnu.elf-x86-64 binary input).
3) Updated comment in dwarfdump-test-zlib.cc.

Original commit message:
[llvm-dwarfdump] - Teach dwarfdump to decompress debug sections in zlib style.

Before this llvm-dwarfdump only recognized zlib-gnu compression style of headers,
this patch adds support for zlib style. 
It looks reasonable to support both styles for dumping,
even if we are not going to suport generating of deprecated gnu one.

Differential revision: http://reviews.llvm.org/D20470

llvm-svn: 270557
2016-05-24 12:48:46 +00:00
George Rimar f059dd4f76 Revert r270543 ("Recommit r270540")
Failed build bot in another test.
I am sorry for noise.
http://lab.llvm.org:8080/green/job/clang-stage1-cmake-RA-incremental_check/23679/testReport/junit/LLVM/DebugInfo/llvm_symbolizer_zlib_test/

llvm-svn: 270547
2016-05-24 11:03:10 +00:00
George Rimar e9b2e19109 Recommit r270540
fix: forgot to commit the updated dwarfdump-test-zlib.elf-x86-64

Original commit message:
[llvm-dwarfdump] - Teach dwarfdump to decompress debug sections in zlib style.

Before this llvm-dwarfdump only recognized zlib-gnu compression style of headers,
this patch adds support for zlib style. 
It looks reasonable to support both styles for dumping,
even if we are not going to suport generating of deprecated gnu one.

Differential revision: http://reviews.llvm.org/D20470

llvm-svn: 270543
2016-05-24 10:46:43 +00:00
George Rimar 6a6185fd78 Revert r270540 "[llvm-dwarfdump] - Teach dwarfdump to decompress debug sections in zlib style."
it broked bot:
http://lab.llvm.org:8011/builders/clang-s390x-linux/builds/5036

llvm-svn: 270541
2016-05-24 09:44:44 +00:00
George Rimar 6bcbf4c572 [llvm-dwarfdump] - Teach dwarfdump to decompress debug sections in zlib style.
Before this llvm-dwarfdump only recognized zlib-gnu compression style of headers,
this patch adds support for zlib style. 
It looks reasonable to support both styles for dumping,
even if we are not going to suport generating of deprecated gnu one.

Differential revision: http://reviews.llvm.org/D20470

llvm-svn: 270540
2016-05-24 09:28:36 +00:00
Kevin Enderby 9873e2c467 Add the printing the Mach-O (__LLVM,__bundle) xar archive file section "verbosely"
to llvm-objdump. This section is created with -fembed-bitcode option.

This requires the use of libxar and the Cmake and lit support were crafted by
Chris Bieneman!

rdar://26202242

llvm-svn: 270491
2016-05-23 21:34:12 +00:00
Rafael Espindola 699281cce7 Don't pass a Reloc::Model to MC.
MC only needs to know if the output is PIC or not. It never has to
decide about creating GOTs and PLTs for example. The only thing that
MC itself uses this information for is expanding "macros" in sparc and
mips. The rest I am pretty sure could be moved to CodeGen.

This is a cleanup and isolates the code from future changes to
Reloc::Model.

llvm-svn: 269909
2016-05-18 11:58:50 +00:00
Lang Hames 8a63b2afc1 [Object] Move isNotObjectErrorInvalidFileType out of header.
llvm-svn: 269848
2016-05-17 21:38:53 +00:00
Kevin Enderby ac9e15551d Change llvm-objdump, llvm-nm and llvm-size when reporting an object file error
when the object is in an archive to use something like libx.a(foo.o) as part of
the error message.

Also changed llvm-objdump and llvm-size to be like llvm-nm and ignore non-object
files in archives and not produce any error message.

To do this Archive::Child::getAsBinary() was changed from ErrorOr<...> to
Expected<...> then that was threaded up to its users.

Converting this interface to Expected<> from ErrorOr<> does involve
touching a number of places. To contain the changes for now the use of
errorToErrorCode() is still used in one place yet to be fully converted.

Again 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 comments for those.

llvm-svn: 269784
2016-05-17 17:10:12 +00:00
Rafael Espindola 83658d6e7a Return a StringRef from getSection.
This is similar to how getName is handled.

llvm-svn: 269218
2016-05-11 18:21:59 +00:00
Rafael Espindola 484983f453 Fix bug where temporary file would be left behind every time an archive was updated.
When updating an existing archive, llvm-ar opens the old archive into a
`MemoryBuffer`, does its thing, and writes the results to a temporary
file. That file is then renamed to the original archive filename, thus
replacing it with the updated contents. However, on Windows at least,
what would happen is that the `MemoryBuffer` for the old archive would
actually be an mmap'ed view of the file, so when it came time to do the
rename via Win32's `ReplaceFile`, it would succeed but would be unable
to fully replace the file since there would still be a handle open on
it; instead, the old version got renamed to a random temporary name and
left behind.

Patch by Cameron!

llvm-svn: 268916
2016-05-09 13:31:11 +00:00
Kevin Enderby d4e075be63 Change GenericBinaryError to no longer include a FileName, which is then not
part of the error message.

As the caller is the one that needs to add the name of where the "object file"
comes from to the error message as the object file could be in an archive, or
coming from a slice of a Mach-O universal file or a buffer created by a JIT.

In the cases of a Mach-O universal file the architecture name may or may not
also need to be printed which is up to the tool code.  For example if the tool
code is only selecting the host architecture slice then that architecture name
is never printed.

This patch is the change to the libObject code and there will be follow on
commits for changes to the code for each tool.

llvm-svn: 268789
2016-05-06 20:16:28 +00:00
Justin Bogner 2a42da996d Object: Fix two -Wpessimizing-move warnings after r268694
llvm-svn: 268697
2016-05-05 23:59:57 +00:00
Kevin Enderby 1e3abcbe76 Fix window bots failures due to r268694 - Cleanup and refactor of malformedError() in lib/Object/MachOObjectFile.cpp .
llvm-svn: 268696
2016-05-05 23:55:27 +00:00
Kevin Enderby 8913496b77 Cleanup and refactor of malformedError() in lib/Object/MachOObjectFile.cpp .
No functional change.

llvm-svn: 268694
2016-05-05 23:41:05 +00:00
Kevin Enderby b34e3a1877 Clean up the specific error message for a malformed Mach-O files with bad segment
load commands.

The existing test case in test/Object/macho-invalid.test for
macho-invalid-too-small-segment-load-command has a cmdsize of 55, while
being too small also it is not a multiple of 4.  So when that check is added
this test case will produce a different error. So I constructed a new test case
that will trigger the intended error.

I also changed the error message to be consistent with the other malformed Mach-O
file error messages which prints the load command index.  I also removed both
object_error::macho_load_segment_too_small and
object_error::macho_load_segment_too_many_sections from Object/Error.h
as they are not needed and can just use object_error::parse_failed and let the
error message string distinguish the specific error.

llvm-svn: 268652
2016-05-05 17:43:35 +00:00
Kevin Enderby a8e3ab0c56 Produce another specific error message for a malformed Mach-O file when a load
command has a size less than 8 bytes.

I think the existing test case in test/Object/macho-invalid.test for
macho64-invalid-too-small-load-command was trying to test for this but that
test case triggered a different error given how it was constructed.  So I
constructed a new test case that would trigger this specific error.

I also changed the error message to be consistent with the other malformed Mach-O
file error messages.  I also removed object_error::macho_small_load_command from
Object/Error.h as it is not needed and can just use object_error::parse_failed
and let the error message string distinguish the error.

llvm-svn: 268463
2016-05-03 23:13:50 +00:00
Kevin Enderby 368e714907 Produce another specific error message for a malformed Mach-O file when a load
command other than the first one is past the end of the load commands.

This is like the test case in test/Object/macho-invalid.test for
macho64-invalid-incomplete-load-command but it is the second load command
that is past the end of all the load commands instead of the first.

The code in the constructor for MachOObjectFile that loops over the load
commands used getNextLoadCommandInfo() which was not producing
a good error message.  So that was fixed and a test case was added.

llvm-svn: 268403
2016-05-03 17:16:08 +00:00
Davide Italiano 8a2593331c [lib/Object] Make this assertion more useful.
llvm-svn: 268367
2016-05-03 07:30:56 +00:00
Rafael Espindola 21507a4a5a Don't try to create thin bsd archives.
Not such variant has been specified yet.

llvm-svn: 268305
2016-05-02 21:06:57 +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
Rafael Espindola 694210cddc Expose a getFullName for thin archive members.
It will be used in lld.

llvm-svn: 268226
2016-05-02 13:45:06 +00:00
Tim Northover 9e8eb418e5 MachO: remove weird ARM/Thumb interface from MachOObjectFile
Only one consumer (llvm-objdump) actually cared about the fact that there were
two triples. Others were actively working around the fact that the Triple
returned by getArch might have been invalid. As for llvm-objdump, it needs to
be acutely aware of both Triples anyway, so being generic in the exposed API is
no benefit.

Also rename the version of getArch returning a Triple. Users were having to
pass an unwanted nullptr to disambiguate the two, which was nasty.

The only functional change here is that armv7m and armv7em object files no
longer crash llvm-objdump.

llvm-svn: 267249
2016-04-22 23:21:13 +00:00
Mehdi Amini a0cb890fb6 Clean the API for CollectAsmUndefinedRefs, taking a Triple and a String InlineAsm instead of a Module (NFC)
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 267106
2016-04-22 04:58:12 +00:00
Mehdi Amini 9ff43e40fa IRObjectFile, clang-format fixup for r267104
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 267105
2016-04-22 04:49:46 +00:00
Mehdi Amini 9a1724bf3d Use std::move on the enum to insert it into the pair to please MSVC
(I have no idea why is it needed)
Fixup for r267103

From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 267104
2016-04-22 04:45:57 +00:00
Mehdi Amini e9cffafdf7 Refactor IRObjectFile, extract a static CollectAsmUndefinedRefs() method to parse inline assembly (NFC)
I plan to call this from ThinLTOCodeGenerator.

From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 267103
2016-04-22 04:28:05 +00:00
Teresa Johnson 6fb3f19959 [ThinLTO] Remove unused/incomplete lazy summary reading support (NFC)
This removes the interfaces added (and not yet complete) to support
lazy reading of summaries. This support is not expected to be needed
since we are moving to a model where the full index is only being
traversed in the thin link step, instead of the back ends.

(The second part of this that I plan to do next is remove the
GlobalValueInfo from the ModuleSummaryIndex - it was mostly needed to
support lazy parsing of summaries. The index can instead reference the
summary structures directly.)

llvm-svn: 267097
2016-04-22 01:52:00 +00:00
Kevin Enderby 6e295f2304 Fix a typo in an error message. Caught by Sean Silva!
llvm-svn: 267056
2016-04-21 21:20:40 +00:00
Kevin Enderby 5e55d17ba7 hange the variable name big_size to BigSize. Caught by Rafael Espíndola!
llvm-svn: 267043
2016-04-21 20:29:49 +00:00
Evgeniy Stepanov 2383465e33 Fix compilation error in r266919.
lib/Object/MachOObjectFile.cpp:53:44: error: moving a temporary object prevents copy elision [-Werror,-Wpessimizing-move]
  return malformedError(Obj.getFileName(), std::move(Msg.str()), ECOverride);

llvm-svn: 266930
2016-04-20 22:44:40 +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
Nico Weber 77729b82e7 Replace a loop with a for-each loop. No behavior change.
llvm-svn: 266903
2016-04-20 19:09:26 +00:00
Mehdi Amini b550cb1750 [NFC] Header cleanup
Removed some unused headers, replaced some headers with forward class declarations.

Found using simple scripts like this one:
clear && ack --cpp -l '#include "llvm/ADT/IndexedMap.h"' | xargs grep -L 'IndexedMap[<]' | xargs grep -n --color=auto 'IndexedMap'

Patch by Eugene Kosov <claprix@yandex.ru>

Differential Revision: http://reviews.llvm.org/D19219

From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 266595
2016-04-18 09:17:29 +00:00
Kevin Enderby 8702574557 Start to add real error messages for malformed Mach-O files.
And update the existing test cases in test/Object/macho-invalid.test
to use llvm-objdump with the -macho option to produce these
error messages and stop producing the generic "Invalid data
was encountered while parsing the file" message.

Working from the beginning of the file, if the mach header is too large for
the size of the file and then if the load commands that follow extend past
the end of the file these two errors now generate correct error messages.

Both of these have existing test cases in test/Object/macho-invalid.test .

But the first with macho-invalid-header it will never trigger the error message
"mach header extends past the end of the file" using any of the llvm tools as
they all use identify_magic() which rejects files with the correct magic number
that are too small in size.  So I tested this by hacking that code and seeing the
error message down in parseHeader() really does happen.  So in case there
is ever code in llvm that directly calls createMachOObjectFile() this error
message will be correctly produced.

The second error message of "load commands extends past the end of the file"
is triggered by a number of existing tests cases in test/Object/macho-invalid.test .
Also other tests trigger different error messages now like "ilocalsym plus
nlocalsym in LC_DYSYMTAB load command extends past the end of the
symbol table".

There are two existing test cases that still get the "Invalid data was encountered ..."
error messages that I will tackle next.  But they will involve a bit of pluming an
Expect<...> up through the call stack and I want to do those as separate changes.

FYI, for those test cases that were trying to test specific errors that now get
different errors I’ll fix those in follow on changes and create new test cases
for those so they test the error they were meant to test.

llvm-svn: 266248
2016-04-13 21:17:58 +00:00
Kevin Enderby 3fcdf6ae2a Thread Expected<...> up from createMachOObjectFile() to allow llvm-objdump to produce a real error message
Produce the first specific error message for a malformed Mach-O file describing
the problem instead of the generic message for object_error::parse_failed of
"Invalid data was encountered while parsing the file”.  Many more good error
messages will follow after this first one.

This is built on Lang Hames’ great work of adding the ’Error' class for
structured error handling and threading Error through MachOObjectFile
construction.  And making createMachOObjectFile return Expected<...> .

So to to get the error to the llvm-obdump tool, I changed the stack of
these methods to also return Expected<...> :

  object::ObjectFile::createObjectFile()
  object::SymbolicFile::createSymbolicFile()
  object::createBinary()

Then finally in ParseInputMachO() in MachODump.cpp the error can
be reported and the specific error message can be printed in llvm-objdump
and can be seen in the existing test case for the existing malformed binary
but with the updated error message.

Converting these interfaces to Expected<> from ErrorOr<> does involve
touching a number of places. To contain the changes for now use of
errorToErrorCode() and errorOrToExpected() are used where the callers
are yet to be converted.

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(ObjOrErr.takeError()) so the buggy code will not crash
since needed to deal with the Error.

Note there is one fix also needed to lld/COFF/InputFiles.cpp 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: 265606
2016-04-06 22:14:09 +00:00
Peter Collingbourne f84646cd95 Object: Correctly read thin archives containing absolute paths.
Differential Revision: http://reviews.llvm.org/D18666

llvm-svn: 265065
2016-03-31 22:08:31 +00:00
David Blaikie b805f73ad1 Remove else after return
llvm-svn: 264599
2016-03-28 17:45:48 +00:00
Lang Hames d1af8fce0f [Support] Switch to RAII helper for error-as-out-parameter idiom.
As discussed on the llvm-commits thread for r264467.

llvm-svn: 264479
2016-03-25 23:54:32 +00:00
Lang Hames ff044b1f69 [Object] Make createMachOObjectFile return Expected<...> rather than
ErrorOr<...>.

llvm-svn: 264473
2016-03-25 23:11:52 +00:00
Lang Hames 8262764869 [Object] Make MachOObjectFile's constructor private, provide a static create
method instead.

This is not quite a named constructor: Construction may fail, and
MachOObjectFiles are usually passed by unique_ptr anyway, so create
returns an Expected<std::unique_ptr<MachOObjectFile>>.

llvm-svn: 264469
2016-03-25 21:59:14 +00:00
Lang Hames 9e964f3728 [Object] Start threading Error through MachOObjectFile construction.
llvm-svn: 264425
2016-03-25 17:25: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
David Majnemer 511391feaa [COFF] Refactor section alignment calculation
Section alignment isn't completely trivial, let it live in one place so
that we may reuse it in LLVM.

llvm-svn: 263722
2016-03-17 16:55:18 +00:00