Now that we've moved to C++14, we no longer need the llvm::make_unique
implementation from STLExtras.h. This patch is a mechanical replacement
of (hopefully) all the llvm::make_unique instances across the monorepo.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@369013 91177308-0d34-0410-b5e6-96231b3b80d8
Changes: no changes. A fix for the clang code will be landed right on top.
Original commit message:
SectionRef::getName() returns std::error_code now.
Returning Expected<> instead has multiple benefits.
For example, it forces user to check the error returned.
Also Expected<> may keep a valuable string error message,
what is more useful than having a error code.
(Object\invalid.test was updated to show the new messages printed.)
This patch makes a change for all users to switch to Expected<> version.
Note: in a few places the error returned was ignored before my changes.
In such places I left them ignored. My intention was to convert the interface
used, and not to improve and/or the existent users in this patch.
(Though I think this is good idea for a follow-ups to revisit such places
and either remove consumeError calls or comment each of them to clarify why
it is OK to have them).
Differential revision: https://reviews.llvm.org/D66089
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@368826 91177308-0d34-0410-b5e6-96231b3b80d8
SectionRef::getName() returns std::error_code now.
Returning Expected<> instead has multiple benefits.
For example, it forces user to check the error returned.
Also Expected<> may keep a valuable string error message,
what is more useful than having a error code.
(Object\invalid.test was updated to show the new messages printed.)
This patch makes a change for all users to switch to Expected<> version.
Note: in a few places the error returned was ignored before my changes.
In such places I left them ignored. My intention was to convert the interface
used, and not to improve and/or the existent users in this patch.
(Though I think this is good idea for a follow-ups to revisit such places
and either remove consumeError calls or comment each of them to clarify why
it is OK to have them).
Differential revision: https://reviews.llvm.org/D66089
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@368812 91177308-0d34-0410-b5e6-96231b3b80d8
Some of these names were abbreviated, some were not, some pluralised,
some not. Made the API difficult to use - since it's an exact 1:1
mapping to the DWARF sections - use those names (changing underscore
separation for camel casing).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@368189 91177308-0d34-0410-b5e6-96231b3b80d8
In r367348, I changed dsymutil to pass the LinkOptions by value isntead
of by const reference. However, the options were still captured by
reference in the LinkLambda. This patch fixes that by passing them in by
value.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@367635 91177308-0d34-0410-b5e6-96231b3b80d8
When looping over the difference architectures in a fat binary, we
modify the link options before dispatching the link step to a different
thread. Passing the options by cont reference is not thread safe, as we
might modify its fields before the whole sturct is copied over.
Given that the link options are already stored in the DwarfLinker, we
can easily fix this by passing a copy of the link options instead of a
reference, which would just get copied later on.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@367348 91177308-0d34-0410-b5e6-96231b3b80d8
It is necessary to generate fixups in .debug_frame or .eh_frame as
relaxation is enabled due to the address delta may be changed after
relaxation.
There is an opcode with 6-bits data in debug frame encoding. So, we
also need 6-bits fixup types.
Differential Revision: https://reviews.llvm.org/D58335
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@366524 91177308-0d34-0410-b5e6-96231b3b80d8
It is necessary to generate fixups in .debug_frame or .eh_frame as
relaxation is enabled due to the address delta may be changed after
relaxation.
There is an opcode with 6-bits data in debug frame encoding. So, we
also need 6-bits fixup types.
Differential Revision: https://reviews.llvm.org/D58335
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@366442 91177308-0d34-0410-b5e6-96231b3b80d8
Before this patch we used either a single thread, or the number of
hardware threads available, effectively ignoring the number of threads
specified on the command line.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@362815 91177308-0d34-0410-b5e6-96231b3b80d8
When running dsymutil on a fat binary, we use temporary files in a small
vector of size four. When processing more than 4 architectures, this
resulted in a user-after-move, because the temporary files got moved to
the heap. Instead of storing an optional temp file, we now use a unique
pointer, so the location of the actual temp file doesn't change.
We could test this by checking in 5 binaries for 5 different
architectures, but this seems wasteful, especially since the number of
elements in the small vector is arbitrary.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@362621 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
For the most part this consists of replacing ${LLVM_TARGETS_TO_BUILD} with
some combination of AllTargets* so that they depend on specific components
of a target backend rather than all of it. The overall effect of this is
that, for example, tools like opt no longer falsely depend on the
disassembler, while tools like llvm-ar no longer depend on the code
generator.
There's a couple quirks to point out here:
* AllTargetsCodeGens is a bit more prevalent than expected. Tools like dsymutil
seem to need it which I was surprised by.
* llvm-xray linked to all the backends but doesn't seem to need any of them.
It builds and passes the tests so that seems to be correct.
* I left gold out as it's not built when binutils is not available so I'm
unable to test it
Reviewers: bogner, JDevlieghere
Reviewed By: bogner
Subscribers: mehdi_amini, mgorny, steven_wu, dexonsmith, rupprecht, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D62331
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@361567 91177308-0d34-0410-b5e6-96231b3b80d8
The dwarf streamer already holds a copy of the link options, so there's
no need to pass them as an argument.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@361276 91177308-0d34-0410-b5e6-96231b3b80d8
r360876 didn't fix 2 call sites in clang.
Expected<ArrayRef<uint8_t>> may be better but use Expected<StringRef> for now.
Follow-up of D61781.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@360892 91177308-0d34-0410-b5e6-96231b3b80d8
It broke the Clang build, see llvm-commits thread.
> Expected<ArrayRef<uint8_t>> may be better but use Expected<StringRef> for now.
>
> Follow-up of D61781.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@360878 91177308-0d34-0410-b5e6-96231b3b80d8
This was meant to be part of the original commit r358921, but somehow
got lost.
<rdar://problem/49751748>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@359010 91177308-0d34-0410-b5e6-96231b3b80d8
When a Swift module built with debug info imports a library without
debug info from a textual interface, the textual interface is
necessary to reconstruct types defined in the library's interface. By
recording the Swift interface files in DWARF dsymutil can collect them
and LLDB can find them.
This patch teaches dsymutil to look for DW_TAG_imported_modules and
records all references to parseable Swift ingterfrace files and copies
them to
a.out.dSYM/Contents/Resources/<Arch>/<ModuleName>.swiftinterface
<rdar://problem/49751748>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@358921 91177308-0d34-0410-b5e6-96231b3b80d8
Continues the work started in r354941. Changes (all but one) uses of the
extractValue to static createFromData.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@355233 91177308-0d34-0410-b5e6-96231b3b80d8
Dsymutil gets library member information is through the ambiguous
/path/to/archive.a(member.o). The current logic we use would get
confused by additional parentheses. Using rfind mitigates this issue.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@355114 91177308-0d34-0410-b5e6-96231b3b80d8
That patch is the fix for https://bugs.llvm.org/show_bug.cgi?id=40703
"wrong line number info for obj file compiled with -ffunction-sections"
bug. The problem happened with only .o files. If object file contains
several .text sections then line number information showed incorrectly.
The reason for this is that DwarfLineTable could not detect section which
corresponds to specified address(because address is the local to the
section). And as the result it could not select proper sequence in the
line table. The fix is to pass SectionIndex with the address. So that it
would be possible to differentiate addresses from various sections. With
this fix llvm-objdump shows correct line numbers for disassembled code.
Differential review: https://reviews.llvm.org/D58194
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@354972 91177308-0d34-0410-b5e6-96231b3b80d8
The DWARF standard says that an empty compile unit is not valid:
> Each such contribution consists of a compilation unit header (see
> Section 7.5.1.1 on page 200) followed by a single DW_TAG_compile_unit or
> DW_TAG_partial_unit debugging information entry, together with its
> children.
Therefore we shouldn't clone them in dsymutil.
Differential revision: https://reviews.llvm.org/D57979
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@353903 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@351636 91177308-0d34-0410-b5e6-96231b3b80d8
An assertion was hit when running dsymutil on a gcc generated binary
that contained an empty address range. Address ranges are stored in an
interval map of half open intervals. Since the interval is empty and
therefore meaningless, we simply don't add it to the map.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@350591 91177308-0d34-0410-b5e6-96231b3b80d8
The unobufscation support for BCSymbolMaps was the last piece of code
that hasn't been upstreamed yet. This patch contains a reworked version
of the existing code and relevant tests.
Differential revision: https://reviews.llvm.org/D56346
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@350580 91177308-0d34-0410-b5e6-96231b3b80d8
After TimePoint's precision was increased in LLVM we started seeing
failures because the modification times didn't match. This adds a time
cast to ensure that we're comparing TimePoints with the same amount of
precision.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@348283 91177308-0d34-0410-b5e6-96231b3b80d8
Usually local symbols will have their address described in the debug
map. Global symbols have to have their address looked up in the symbol
table of the main executable. By playing with 'ld -r' and export lists,
you can get a symbol described as global by the debug map while actually
being a local symbol as far as the link in concerned. By gathering the
address of local symbols, we fix this issue.
Also, we prefer a global symbol in case of a name collision to preserve
the previous behavior.
Note that using the 'ld -r' tricks, people can actually cause symbol
names collisions that dsymutil has no way to figure out. This fixes the
simple case where there is only one symbol of a given name.
rdar://problem/32826621
Differential revision: https://reviews.llvm.org/D54922
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@348021 91177308-0d34-0410-b5e6-96231b3b80d8
LC_BUILD_VERSION contains platform information that is useful for LLDB
to match up dSYM bundles with binaries. This patch copies the load
command over into the dSYM.
rdar://problem/44145175
rdar://problem/45883463
Differential Revision: https://reviews.llvm.org/D54233
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@346412 91177308-0d34-0410-b5e6-96231b3b80d8
The purpose of this patch is twofold:
- Fold pre-DWARF v5 functionality into v5 to eliminate the need for 2 different
versions of range list handling. We get rid of DWARFDebugRangelist{.cpp,.h}.
- Templatize the handling of range list tables so that location list handling
can take advantage of it as well. Location list and range list tables have the
same basic layout.
A non-NFC version of this patch was previously submitted with r342218, but it caused
errors with some TSan tests. This patch has no functional changes. The difference to
the non-NFC patch is that there are no changes to rangelist dumping in this patch.
Differential Revision: https://reviews.llvm.org/D53545
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@345546 91177308-0d34-0410-b5e6-96231b3b80d8
Before this patch we were returning an empty string in case we couldn't
create the output file. Now we return an expected string so we can
return and print the proper issue. We now return errors instead of bools
and defer printing to the call site.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@344983 91177308-0d34-0410-b5e6-96231b3b80d8
