This patch splits off some abstractions used by dsymutil's dwarf linker
and moves them into separate header and implementation files. This
almost halves the number of LOC in DwarfLinker.cpp and makes it a lot
easier to understand what functionality lives where.
Differential revision: https://reviews.llvm.org/D48647
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@335749 91177308-0d34-0410-b5e6-96231b3b80d8
Create convenience functions for printing error, warning and note to
stdout. Previously we had similar functions being used in dsymutil, but
given that this pattern is so common it makes sense to make it available
globally.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@330091 91177308-0d34-0410-b5e6-96231b3b80d8
When running dsymutil as part of your build system, it can be desirable
for warnings to be part of the end product, rather than just being
emitted to the output stream. This patch upstreams that functionality.
Differential revision: https://reviews.llvm.org/D44639
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@328965 91177308-0d34-0410-b5e6-96231b3b80d8
Make the architecture part of the warning in the DebugMapParser. This
makes things consistent with the Apple's internal version of dsymutil.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@327485 91177308-0d34-0410-b5e6-96231b3b80d8
This is a follow-up to r327137 where we unified error handling for the
DwarfLinker. This replaces calls to errs() and outs() with the
appropriate ostream wrapper everywhere in dsymutil.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@327411 91177308-0d34-0410-b5e6-96231b3b80d8
With autobrief enabled, these server no purpose anymore. Most of them
were already removed but this makes everything consistent.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@325769 91177308-0d34-0410-b5e6-96231b3b80d8
Some over-due gardening: this fixes a bunch of typos and makes the
formatting consistent with LLVM's style guide.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@325768 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
swiftc emits symbols without flags set, which led dsymutil to ignore
them when searching for global symbols, causing dwarf location data
to be omitted. Xcode's dsymutil handles this case correctly, and emits
valid location data. Add this functionality to llvm-dsymutil by
allowing parsing of symbols with no flags set.
Reviewers: aprantl, friss, JDevlieghere
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D38587
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@315218 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
swiftc emits symbols without flags set, which led dsymutil to ignore
them when searching for global symbols, causing dwarf location data
to be omitted. Xcode's dsymutil handles this case correctly, and emits
valid location data. Add this functionality to llvm-dsymutil by
allowing parsing of symbols with no flags set.
Reviewers: aprantl, friss, JDevlieghere
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D38587
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@315082 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@315066 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@315014 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@315004 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@314198 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@286358 91177308-0d34-0410-b5e6-96231b3b80d8
If the result of the find is only used to compare against end(), just
use is_contained instead.
No functionality change is intended.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@278433 91177308-0d34-0410-b5e6-96231b3b80d8
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).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@268894 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@268298 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@267249 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@266919 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@264187 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@259318 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@259317 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@255350 91177308-0d34-0410-b5e6-96231b3b80d8
This option dumps the STAB entries that define the debug map(s)
stored in the input binaries, and then exits.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@246403 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@246011 91177308-0d34-0410-b5e6-96231b3b80d8
This function can actually fail since the symbol contains an index to the
section and that can be invalid.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@244375 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@244160 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@244087 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@243096 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@243095 91177308-0d34-0410-b5e6-96231b3b80d8
The debug map contains the timestamp of the object files in references.
We do not check these in the general case, but it's really useful if
you have archives where different versions of an object file have been
appended. This allows llvm-dsymutil to find the right one.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@242965 91177308-0d34-0410-b5e6-96231b3b80d8
getSymbolValue now returns a value that in convenient for most callers:
* 0 for undefined
* symbol size for common symbols
* offset/address for symbols the rest
Code that needs something more specific can check getSymbolFlags.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@241605 91177308-0d34-0410-b5e6-96231b3b80d8
At least not in the interface exposed by ObjectFile. This matches what ELF and
COFF implement.
Adjust existing code that was expecting them to have values. No overall
functionality change intended.
Another option would be to change the interface and the ELF and COFF
implementations to say that the value of a common symbol is its size.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@241593 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@241297 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@240777 91177308-0d34-0410-b5e6-96231b3b80d8
COFF and MachO only define symbol sizes for common symbols. Reflect that
in the class hierarchy by having a method for common symbols only in the base
and a general one in ELF.
This avoids the need of using a magic value for the size, which had a few
problems
* Most callers didn't check for it.
* The ones that did could not tell the magic value from a file actually having
that value.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@240529 91177308-0d34-0410-b5e6-96231b3b80d8
It will get a bit bigger in an upcoming commit. No need to have all
of that in the header.
Also move parseYAMLDebugMap() to the same place as the serialization
code. This way it will be able to share a private Context object with
it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@239185 91177308-0d34-0410-b5e6-96231b3b80d8
With a couple more constructors that GCC thinks are necessary.
Original commit message:
[dsymutil] Accept a YAML debug map as input instead of a binary.
To do this, the user needs to pass the new -y flag.
As it wasn't tested before, the debug map YAML deserialization was
completely buggy (mainly because the DebugMapObject has a dual
mapping that allows to search by name and by address, but only the
StringMap got populated). It's fixed and tested in this commit by
augmenting some test with a 2 stage dwarf link: a frist llvm-dsymutil
reads the debug map and pipes it in a second instance that does the
actual link without touching the initial binary.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@238959 91177308-0d34-0410-b5e6-96231b3b80d8
