Revert "[llvm-dsymutil] Add support for __swift_ast MachO DWARF section"

Breaks aarch64 builders

This reverts commit r315014.

llvm-svn: 315034

[llvm-dsymutil] Add support for __swift_ast MachO DWARF section

Summary:
Xcode's dsymutil emits a __swift_ast DWARF section, which is required for debugging,
and which contains a byte-for-byte dump

[llvm-dsymutil] Add support for __swift_ast MachO DWARF section

Summary:
Xcode's dsymutil emits a __swift_ast DWARF section, which is required for debugging,
and which contains a byte-for-byte dump of the swiftmodule file.
Add this feature to llvm-dsymutil.

Tested with `gobjdump --dwarf=info -s`, by verifying that the contents of
`__DWARF.__swift_ast` match between Xcode's dsymutil and llvm-dsymutil
(Xcode's dwarfdump and llvm-dwarfdump don't currently recognize the
__swift_ast section).

Reviewers: aprantl, friss

Subscribers: llvm-commits, JDevlieghere

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

llvm-svn: 315014

show more ...

Revert "[llvm-dsymutil] Add support for __swift_ast MachO DWARF section"

This reverts commit r315004, because of a failing test on non-apple platforms

llvm-svn: 315009

[llvm-dsymutil] Add support for __swift_ast MachO DWARF section

Summary:
Xcode's dsymutil emits a __swift_ast DWARF section, which is required for debugging,
and which contains a byte-for-byte dump

[llvm-dsymutil] Add support for __swift_ast MachO DWARF section

Summary:
Xcode's dsymutil emits a __swift_ast DWARF section, which is required for debugging,
and which contains a byte-for-byte dump of the swiftmodule file.
Add this feature to llvm-dsymutil.

Tested with `gobjdump --dwarf=info -s`, by verifying that the contents of
`__DWARF.__swift_ast` match between Xcode's dsymutil and llvm-dsymutil
(Xcode's dwarfdump and llvm-dwarfdump don't currently recognize the
__swift_ast section).

Reviewers: aprantl, friss

Subscribers: llvm-commits, JDevlieghere

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

llvm-svn: 315004

show more ...

[dsymutil] Better support for symbol aliases

This patch adds logic to follow a symbol's aliases when the symbol name
cannot be found in the current object file. It checks the main binary
for the sym

[dsymutil] Better support for symbol aliases

This patch adds logic to follow a symbol's aliases when the symbol name
cannot be found in the current object file. It checks the main binary
for the symbol's address and queries the current object for its aliases
(symbols with the same address) before printing out a warning.

Differential revision: https://reviews.llvm.org/D38230

llvm-svn: 314198

show more ...

[dsymutil] Replace TimeValue with TimePoint

Summary:
All changes are pretty straight-forward. I chose to use TimePoints with
second precision, as that is all that seems to be required here.

Reviewe

[dsymutil] Replace TimeValue with TimePoint

Summary:
All changes are pretty straight-forward. I chose to use TimePoints with
second precision, as that is all that seems to be required here.

Reviewers: friss, zturner

Subscribers: llvm-commits

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

llvm-svn: 286358

show more ...

SymbolRef::Type is not a bitfield and must be compared directly

Found by PVS-Studio.

llvm-svn: 285597

Use the range variant of find instead of unpacking begin/end

If the result of the find is only used to compare against end(), just
use is_contained instead.

No functionality change is intended.

ll

Use the range variant of find instead of unpacking begin/end

If the result of the find is only used to compare against end(), just
use is_contained instead.

No functionality change is intended.

llvm-svn: 278433

show more ...

[dsymutil] Fix -arch option for thumb variants.

r267249 removed the dual ARM/Thumb interface from MachOObjectFile,
simplifying llvm-dsymutil's code. This unfortunately also regressed
llvm-dsymutil's

[dsymutil] Fix -arch option for thumb variants.

r267249 removed the dual ARM/Thumb interface from MachOObjectFile,
simplifying llvm-dsymutil's code. This unfortunately also regressed
llvm-dsymutil's ability to select thumb slices, because the simplified
code was also dealing with the discrepency between the slice arch
(eg. armv7m) and the triple arch name (eg. thumbv7m).

llvm-svn: 268894

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 ...

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

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

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 ...

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 ...

[dsymutil] Fix handling of common symbols.

llvm-dsymutil was misinterpreting the value of common symbols as their
address when it actually contains their size. This didn't impact
llvm-dsymutil's abi

[dsymutil] Fix handling of common symbols.

llvm-dsymutil was misinterpreting the value of common symbols as their
address when it actually contains their size. This didn't impact
llvm-dsymutil's ability to link the debug information for common symbols
because these are always found by name and not by address. Things could
however go wrong when the size of a common object matched the object
file address of another symbol. Depending on the link order of the symbols
the common object might incorrectly evict this other object from the
address to symbol mapping, and then link the evicted symbol with a wrong
binary address.

Use the new ability to have symbols without an object file address to fix
this.

llvm-svn: 259318

show more ...

[dsymutil] Allow debug map mappings with no object file address. NFC

This change just changes the data structure that ties symbol names,
object file address and linked binary addresses to accept map

[dsymutil] Allow debug map mappings with no object file address. NFC

This change just changes the data structure that ties symbol names,
object file address and linked binary addresses to accept mappings
with no object file address. Such symbol mappings are not fed into
the debug map yet, so this patch is NFC.
A subsequent patch will make use of this functionality for common
symbols.

llvm-svn: 259317

show more ...

[dsymutil] Ignore absolute symbols in the debug map

Quoting from the comment added to the code:

// Objective-C on i386 uses artificial absolute symbols to
// perform some link time checks.

[dsymutil] Ignore absolute symbols in the debug map

Quoting from the comment added to the code:

// Objective-C on i386 uses artificial absolute symbols to
// perform some link time checks. Those symbols have a fixed 0
// address that might conflict with real symbols in the object
// file. As I cannot see a way for absolute symbols to find
// their way into the debug information, let's just ignore those.

llvm-svn: 255350

show more ...

Fix Clang-tidy modernize-use-nullptr warnings in source directories and generated files; other minor cleanups.

Patch by Eugene Zelenko!

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

llvm-s

Fix Clang-tidy modernize-use-nullptr warnings in source directories and generated files; other minor cleanups.

Patch by Eugene Zelenko!

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

llvm-svn: 249482

show more ...

[dsymutil] Do not construct a StringRef from a std::string temporary

llvm-svn: 246404

[dsymutil] Implement -symtab/-s option.

This option dumps the STAB entries that define the debug map(s)
stored in the input binaries, and then exits.

llvm-svn: 246403

[dsymutil] Store an optional BinaryPath in the debug map.

llvm-dsymutil needs to emit dSYM companion bundles. These are binary files
that replicate some of the orignal binary file properties (sectio

[dsymutil] Store an optional BinaryPath in the debug map.

llvm-dsymutil needs to emit dSYM companion bundles. These are binary files
that replicate some of the orignal binary file properties (sections and
symbols). To get acces to these properties, pass the binary path in the
debug map.

llvm-svn: 246011

show more ...

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

[dsymutil] Add support for the -arch option.

This option allows to select a subset of the architectures when
performing a universal binary link. The filter is done completely
in the mach-o specific

[dsymutil] Add support for the -arch option.

This option allows to select a subset of the architectures when
performing a universal binary link. The filter is done completely
in the mach-o specific part of the code.

llvm-svn: 244160

show more ...

[dsymutil] Implement support for handling mach-o universal binaries as main input/output.

The DWARF linker isn't touched by this, the implementation links
individual files and merges them together i

[dsymutil] Implement support for handling mach-o universal binaries as main input/output.

The DWARF linker isn't touched by this, the implementation links
individual files and merges them together into a fat binary by
calling out to the 'lipo' utility.

The main change is that the MachODebugMapParser can now return
multiple debug maps for a single binary.

The test just verifies that lipo would be invoked correctly, but
doesn't actually generate a binary. This mimics the way clang
tests its external iplatform tools integration.

llvm-svn: 244087

show more ...

[dsymutil] Implement support for universal mach-o object files.

This patch allows llvm-dsymutil to read universal (aka fat) macho object
files and archives. The patch touches nearly everything in th

[dsymutil] Implement support for universal mach-o object files.

This patch allows llvm-dsymutil to read universal (aka fat) macho object
files and archives. The patch touches nearly everything in the BinaryHolder,
but it is fairly mechinical: the methods that returned MemoryBufferRefs or
ObjectFiles now return a vector of those, and the high-level access function
takes a triple argument to select the architecture.

There is no support yet for handling fat executables and thus no support for
writing fat object files.

llvm-svn: 243096

show more ...

[dsymutil] Make the triple detection more strict.

MachOObjectFile offers a method for detecting the correct triple, use
it instead of the previous approximation. This doesn't matter right
now, but i

[dsymutil] Make the triple detection more strict.

MachOObjectFile offers a method for detecting the correct triple, use
it instead of the previous approximation. This doesn't matter right
now, but it will become important for mach-o universal (fat) binaries.

llvm-svn: 243095

show more ...