[lli] Simplify the code a bit. No functional change intended.

llvm-svn: 286555

[lli/COFF] Set the correct alignment for common symbols

Otherwise we set it always to zero, which is not correct,
and we assert inside alignTo (Assertion failed:
Align != 0u && "Align can't be 0.").

[lli/COFF] Set the correct alignment for common symbols

Otherwise we set it always to zero, which is not correct,
and we assert inside alignTo (Assertion failed:
Align != 0u && "Align can't be 0.").

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

llvm-svn: 285841

show more ...

[COFFObjectFile] Ignore broken symbol table

When binaries are compressed by UPX, information about symbol table
offset and symbol count remain unchanged (but became invalid due to
compression).
This

[COFFObjectFile] Ignore broken symbol table

When binaries are compressed by UPX, information about symbol table
offset and symbol count remain unchanged (but became invalid due to
compression).
This causes failure in the constructor and the rest of the binary cannot
be processed.

Instead, reset symbol related information (symbol/string table pointers,
sizes) - this should disable the related iterators and functions while
the rest of the binary can still be processed.

Patch by Bandzi Michal!

llvm-svn: 280147

show more ...

Re-commit r278066: Do not ignore SizeOfOptionalHeader in COFF header even if PE header is not present.

llvm-svn: 278429

CodeView: extract the OMF Directory Header

The DebugDirectory contains a pointer to the CodeView info structure which is a
derivative of the OMF debug directory. The structure has evolved a bit ove

CodeView: extract the OMF Directory Header

The DebugDirectory contains a pointer to the CodeView info structure which is a
derivative of the OMF debug directory. The structure has evolved a bit over
time, and PDB 2.0 used a slightly different definition from PDB 7.0. Both of
these are specific to CodeView and not COFF. Reflect this by moving the
structure definitions into the DebugInfo/CodeView headers. Define a generic
DebugInfo union type that can be used to pass around a reference to the
DebugInfo irrespective of the versioning. NFC.

llvm-svn: 278075

show more ...

Revert "Do not ignore SizeOfOptionalHeader in COFF header even if PE header is not present."

This reverts commit r278066 to unbreak buildbots.

llvm-svn: 278070

Do not ignore SizeOfOptionalHeader in COFF header even if PE header is not present.

Attribute SizeOfOptionalHeader is ignored if no PE header is present
in the file. This attribute should be ignored

Do not ignore SizeOfOptionalHeader in COFF header even if PE header is not present.

Attribute SizeOfOptionalHeader is ignored if no PE header is present
in the file. This attribute should be ignored according to standard,
however there are uses of this field even though it should not be used.

This change does not conform to PE/COFF standard, but there are several
COFF files without PE header, where you had to add up SizeOfOptionalHeader
in order to get proper section headers. Other tools and their own parsers
do take this into account.

Patch by Marek Milkovič!

https://reviews.llvm.org/D22750

llvm-svn: 278066

show more ...

[COFF] Expose iterators for ImportAddressTableRVA

Patch by Bandzi Michal!

llvm-svn: 277298

[COFF] Remove a duplicate import_directory_table_entry definition

We had import_directory_table_entry and
coff_import_directory_table_entry, remove one. Also, factor out the
logic which determins i

[COFF] Remove a duplicate import_directory_table_entry definition

We had import_directory_table_entry and
coff_import_directory_table_entry, remove one. Also, factor out the
logic which determins if a descriptor is a terminator.

llvm-svn: 277296

show more ...

[Object, COFF] An import data directory might not consist soley of imports

The last import is the penultimate entry, the last entry is nulled out.
Data beyond the null entry should not be considered

[Object, COFF] An import data directory might not consist soley of imports

The last import is the penultimate entry, the last entry is nulled out.
Data beyond the null entry should not be considered to hold import
entries.

This fixes PR28302.

N.B. I am working on a reduced testcase, the one in PR28302 is too
large.

llvm-svn: 273790

show more ...

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
t

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

show more ...

[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

[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

show more ...

[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
whethe

[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

show more ...

[Object] Return an error code instead of asserting

This makes it easier to report errors up the stack.

llvm-svn: 271140

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
(be

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

show more ...

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/Debu

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

show more ...

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

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

show more ...

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

[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 styl

[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

show more ...

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

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

show more ...

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

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

show more ...

[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/IndexedM

[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

show more ...

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

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

show more ...

[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

[Object][COFF] Revert r258665 - It doesn't do what I had intended.

I'm discussing the right approach for tracking visibility for COFF symbols on
the llvm-dev list.

llvm-svn: 258666