| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
This is a follow-up for D71546 to add a corresponding unit test.
Differential Revision: https://reviews.llvm.org/D72695
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change is for those who use lld as a library. Context:
https://reviews.llvm.org/D70287
This patch adds a new parmeter to lld::*::link() so that we can pass
an raw_ostream object representing stdout. Previously, lld::*::link()
took only an stderr object.
Justification for making stdoutOS and stderrOS mandatory: I wanted to
make link() functions to take stdout and stderr in that order.
However, if we change the function signature from
bool link(ArrayRef<const char *> args, bool canExitEarly,
raw_ostream &stderrOS = llvm::errs());
to
bool link(ArrayRef<const char *> args, bool canExitEarly,
raw_ostream &stdoutOS = llvm::outs(),
raw_ostream &stderrOS = llvm::errs());
, then the meaning of existing code that passes stderrOS silently
changes (stderrOS would be interpreted as stdoutOS). So, I chose to
make existing code not to compile, so that developers can fix their
code.
Differential Revision: https://reviews.llvm.org/D70292
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 351636
|
|
|
|
|
|
|
|
|
| |
This matches what is done in MachONormalizedFileBinaryWriterTests.cpp
already.
Differential Revision: https://reviews.llvm.org/D46743
llvm-svn: 332114
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We currently use target_link_libraries without an explicit scope
specifier (INTERFACE, PRIVATE or PUBLIC) when linking executables.
Dependencies added in this way apply to both the target and its
dependencies, i.e. they become part of the executable's link interface
and are transitive.
Transitive dependencies generally don't make sense for executables,
since you wouldn't normally be linking against an executable. This also
causes issues for generating install export files when using
LLVM_DISTRIBUTION_COMPONENTS. For example, clang has a lot of LLVM
library dependencies, which are currently added as interface
dependencies. If clang is in the distribution components but the LLVM
libraries it depends on aren't (which is a perfectly legitimate use case
if the LLVM libraries are being built static and there are therefore no
run-time dependencies on them), CMake will complain about the LLVM
libraries not being in export set when attempting to generate the
install export file for clang. This is reasonable behavior on CMake's
part, and the right thing is for LLVM's build system to explicitly use
PRIVATE dependencies for executables.
Unfortunately, CMake doesn't allow you to mix and match the keyword and
non-keyword target_link_libraries signatures for a single target; i.e.,
if a single call to target_link_libraries for a particular target uses
one of the INTERFACE, PRIVATE, or PUBLIC keywords, all other calls must
also be updated to use those keywords. This means we must do this change
in a single shot. I also fully expect to have missed some instances; I
tested by enabling all the projects in the monorepo (except dragonegg),
and configuring both with and without shared libraries, on both Darwin
and Linux, but I'm planning to rely on the buildbots for other
configurations (since it should be pretty easy to fix those).
Even after this change, we still have a lot of target_link_libraries
calls that don't specify a scope keyword, mostly for shared libraries.
I'm thinking about addressing those in a follow-up, but that's a
separate change IMO.
Differential Revision: https://reviews.llvm.org/D40823
llvm-svn: 319840
|
|
|
|
|
|
|
|
|
|
|
|
| |
This creates a new library called BinaryFormat that has all of
the headers from llvm/Support containing structure and layout
definitions for various types of binary formats like dwarf, coff,
elf, etc as well as the code for identifying a file from its
magic.
Differential Revision: https://reviews.llvm.org/D33843
llvm-svn: 304864
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Windows does not allow opened files to be removed. This patch
fixes two types of errors.
- Output file being the same as input file. Because LLD itself
holds a file descriptor of the input file, it cannot create an
output file with the same name as a new file.
- Removing files before releasing MemoryBuffer objects.
These tests are not failing no because MemoryBuffer happens to
decide not to use mmap on these files. But we shouldn't rely on
that behavior.
llvm-svn: 280507
|
|
|
|
|
|
| |
Differential revision: http://reviews.llvm.org/D19348
llvm-svn: 267008
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Note, this is https://llvm.org/bugs/show_bug.cgi?id=27187.
The problem here was that just converting an error to a bool doesn't
always set the checked bit. We only set that bit if the Error didn't
actually contain an error. Otherwise we'd end potentially up silently
dropping it.
Instead just use the consumeError method which is designed to allow us
to drop an error.
llvm-svn: 265311
|
|
|
|
| |
llvm-svn: 264981
|
|
|
|
| |
llvm-svn: 264973
|
|
|
|
|
|
|
| |
This converts almost all of the error handling in atom creation
to llvm::Error instead of std::error_code.
llvm-svn: 264968
|
|
|
|
|
|
|
|
|
|
| |
This is breaking http://lab.llvm.org:8011/builders/lld-x86_64-win7/builds/31647/steps/test%20lld/logs/stdio.
The issue seems to be that it can't write to a file in /tmp, probably because that path doesn't
exist on Windows. This was failing after I added EXPECT_FALSE(ec) in r264961 for the error
handling migration.
llvm-svn: 264962
|
|
|
|
|
|
|
| |
This converts the writeFile method, as well as some of the ones it calls
in the normalized binary file writer and yaml writer.
llvm-svn: 264961
|
|
|
|
|
|
| |
Differential revision: http://reviews.llvm.org/D18232
llvm-svn: 263968
|
|
|
|
| |
llvm-svn: 234415
|
|
|
|
|
|
|
| |
This is the final step of conversion. Now log2 numbers are removed
from everywhere!
llvm-svn: 233246
|
|
|
|
|
|
|
|
| |
This patch defines implicit conversion between integers and PowerOf2
instances, so uses of the classes is now implicit and look like
regular integers. Now we are ready to remove the scaffolding.
llvm-svn: 233245
|
|
|
|
|
|
|
| |
The new constructor's type is the same, but this one takes not a log2
value but an alignment value itself, so the meaning is totally differnet.
llvm-svn: 233244
|
|
|
|
|
|
|
| |
Ban conversion from integers to PowerOf2 even if explicit
to make all places we create PowerOf2 instances visible.
llvm-svn: 233243
|
|
|
|
|
|
|
|
|
|
| |
This patch is to make instantiation and conversion to an integer explicit,
so that we can mechanically replace all occurrences of the class with
integer in the next step.
Now get() returns an alignment value rather than its log2 value.
llvm-svn: 233242
|
|
|
|
|
|
|
|
|
|
|
|
| |
Mach-O normalized file reader assumes that the entire file is aligned
to a large boundary. If the in-memory file is not aligned properly, it will
abort with an assertion failure in read32/read64. This patch forces the
in-memory file for the unit test to be aligned at 64-byte boundary.
I found these tests are failing on Windows, but theoretically they could
fail on other platform.
llvm-svn: 221508
|
|
|
|
| |
llvm-svn: 220131
|
|
|
|
| |
llvm-svn: 218646
|
|
|
|
| |
llvm-svn: 212407
|
|
|
|
| |
llvm-svn: 210820
|
|
|
|
| |
llvm-svn: 210801
|
|
|
|
|
|
| |
This will reduce the noise in a followup patch.
llvm-svn: 210800
|
|
|
|
| |
llvm-svn: 210799
|
|
|
|
| |
llvm-svn: 210781
|
|
|
|
|
|
|
|
| |
This results in some simplifications to the code where an OwningPtr had to
be used with the previous api and then ownership moved to a unique_ptr for
the rest of lld.
llvm-svn: 203809
|
|
|
|
| |
llvm-svn: 203666
|
|
|
|
| |
llvm-svn: 200649
|
|
|
|
| |
llvm-svn: 199259
|
|
|
|
| |
llvm-svn: 199164
|
|
|
|
| |
llvm-svn: 199155
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The main goal of this patch is to allow "mach-o encoded as yaml" and "native
encoded as yaml" documents to be intermixed. They are distinguished via
yaml tags at the start of the document. This will enable all mach-o test cases
to be written using yaml instead of checking in object files.
The Registry was extend to allow yaml tag handlers to be registered. The
mach-o Reader adds a yaml tag handler for the tag "!mach-o".
Additionally, this patch fixes some buffer ownership issues. When parsing
mach-o binaries, the mach-o atoms can have pointers back into the memory
mapped .o file. But with yaml encoded mach-o, name and content are ephemeral,
so a copyRefs parameter was added to cause the mach-o atoms to make their
own copy.
llvm-svn: 198986
|
|
|
|
| |
llvm-svn: 198728
|
|
|
|
| |
llvm-svn: 198725
|
|
|
|
|
|
| |
normalizedToAtoms.
llvm-svn: 198459
|
|
|
|
| |
llvm-svn: 194292
|
|
|
|
| |
llvm-svn: 194187
|
|
|
|
| |
llvm-svn: 194186
|
|
|
|
| |
llvm-svn: 194173
|
|
|
|
|
|
|
|
|
|
| |
This patch adds support for converting normalized mach-o to and from binary
mach-o. It also changes WriterMachO (which previously directly wrote a
mach-o binary given a set of Atoms) to instead do it in two steps. The first
step uses normalizedFromAtoms() to convert Atoms to normalized mach-o, and the
second step uses writeBinary() which to generate the mach-o binary file.
llvm-svn: 194167
|
|
|
|
| |
llvm-svn: 192153
|
|
|
|
| |
llvm-svn: 192152
|
|
This is the first step in how I plan to get mach-o object files support into
lld. We need to be able to test the mach-o Reader and Write on systems without
a mach-o tools. Therefore, we want to support a textual way (YAML) to represent
mach-o files.
MachONormalizedFile.h defines an in-memory abstraction of the content of mach-o
files. The in-memory data structures are always native endianess and always
use 64-bit sizes. That internal data structure can then be converted to or
from three different formats: 1) yaml (text) encoded mach-o, 2) binary mach-o
files, 3) lld Atoms.
This patch defines the internal model and uses YAML I/O to implement the
conversion to and from the model to yaml. The next patch will implement
the conversion from normalized to binary mach-o.
This patch includes unit tests to validate the yaml conversion APIs.
llvm-svn: 192147
|