Summary:
This continues the patch series to eliminate StringRef forms of GNU triples
from the internals of LLVM that began in r239036.
Reviewers: rengolin
Reviewed By: rengolin
Subscribers: llvm-commits, rengolin
Differential Revision: http://reviews.llvm.org/D10381
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@239815 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This affects other tools so the previous C++ API has been retained as a
deprecated function for the moment. Clang has been updated with a trivial
patch (not covered by the pre-commit review) to avoid breaking -Werror builds.
Other in-tree tools will be fixed with similar patches.
This continues the patch series to eliminate StringRef forms of GNU triples
from the internals of LLVM that began in r239036.
The first time this was committed it accidentally fixed an inconsistency in
triples in llvm-mc and this caused a failure. This inconsistency was fixed in
r239808.
Reviewers: rengolin
Reviewed By: rengolin
Subscribers: llvm-commits, rengolin
Differential Revision: http://reviews.llvm.org/D10366
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@239812 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
GetTarget() may modify TripleName without also updating TheTriple.
This can lead to situations where the MCObjectStreamer has a different triple
to the rest of LLVM.
This inconsistency caused sparc-little-endian.s to pass on Windows because most
of LLVM had sparcel-pc-win32 while MCObjectStreamer had "". I believe the same
kind of thing was also true of Darwin.
Reviewers: rengolin
Reviewed By: rengolin
Subscribers: llvm-commits, rengolin, rafael
Differential Revision: http://reviews.llvm.org/D10450
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@239808 91177308-0d34-0410-b5e6-96231b3b80d8
Fix a build failure with `LLVM_ENABLE_MODULES` due to
`ProfileData::instr` conflicting with a function `instr()` in
`<curses.h>`.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@239793 91177308-0d34-0410-b5e6-96231b3b80d8
This commit connects the machine function analysis pass (which creates machine
functions) to the MIR parser, which will initialize the machine functions
with the state from the MIR file and reconstruct the machine IR.
This commit introduces a new interface called 'MachineFunctionInitializer',
which can be used to provide custom initialization for the machine functions.
This commit also introduces a new diagnostic class called
'DiagnosticInfoMIRParser' which is used for MIR parsing errors.
This commit modifies the default diagnostic handling in LLVMContext - now the
the diagnostics are printed directly into llvm::errs() so that the MIR parsing
errors can be printed with colours.
Reviewers: Justin Bogner
Differential Revision: http://reviews.llvm.org/D9928
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@239753 91177308-0d34-0410-b5e6-96231b3b80d8
The plugin now save the bitcode before and after optimizations and the
.o that is passed to the linker.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@239726 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This affects other tools so the previous C++ API has been retained as a
deprecated function for the moment. Clang has been updated with a trivial
patch (not covered by the pre-commit review) to avoid breaking -Werror builds.
Other in-tree tools will be fixed with similar trivial patches.
This continues the patch series to eliminate StringRef forms of GNU triples
from the internals of LLVM that began in r239036.
Reviewers: rengolin
Reviewed By: rengolin
Subscribers: llvm-commits, rengolin
Differential Revision: http://reviews.llvm.org/D10366
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@239721 91177308-0d34-0410-b5e6-96231b3b80d8
into partitions. Also, add an option to clone stub definitions (not just decls)
into partitions: these definitions could be inlined in some places to avoid the
overhead of calling via the stub.
Found by inspection - no test case yet, although I plan to add a unit test for
this once the CompileOnDemand layer refactoring settles down.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@239640 91177308-0d34-0410-b5e6-96231b3b80d8
As suggested by jroelofs in a prior review (D9752),
it makes sense to generally prefer multi-line format.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@239632 91177308-0d34-0410-b5e6-96231b3b80d8
The underlaying issues is that this code can't really know if an OS specific or
processor specific section number should return true or false.
One option would be to assert or return an error, but that looks like over
engineering since extensions are not that common.
It seems better to have these be direct implementation of the ELF spec so that
they are natural for someone familiar with ELF reading the code.
Code that does have to handle OS/Architecture specific values can do it at
a higher level.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@239618 91177308-0d34-0410-b5e6-96231b3b80d8
make_error_code(object_error) is slow because object::object_category()
uses a ManagedStatic variable. But the real problem is that the function is
called too frequently. This patch uses std::error_code() instead of
object_error::success. In most cases, we return "success", so this patch
reduces number of function calls to that function.
http://reviews.llvm.org/D10333
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@239409 91177308-0d34-0410-b5e6-96231b3b80d8
Linking the debug frame section is actually very easy as we just have to
patch the start address in the FDE header and then copy the rest of the
FDE without even looking at it. The only small complexity comes from the
handling of the CIEs that we should unique across object file. This is
also really easy by using a StringMap keyed on the raw contents of the
CIE.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@239198 91177308-0d34-0410-b5e6-96231b3b80d8
Anyway having the type and the name of the member being the same
thing wasn't the wisest of the choices.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@239190 91177308-0d34-0410-b5e6-96231b3b80d8
The main use of the YAML debug map format is for testing inside LLVM. If we have IR
files in the tests used to generate object files, then we obviously don't know the
addresses of the symbols inside the object files beforehand.
This change lets the YAML import lookup the addresses in the object files and rewrite
them. This will allow to have test that really don't need any binary input.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@239189 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
* If the input file is missing;
* If the type of input object file can't be recognized;
* If the object file can't be parsed correctly.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@239065 91177308-0d34-0410-b5e6-96231b3b80d8
We already handled a section with no symbols, extend that to also handle a
section with symbols that don't include the section start.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@239039 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Now users don't have to manually deal with getFirstLoadCommandInfo() /
getNextLoadCommandInfo(), calculate the number of load segments, etc.
No functionality change.
Test Plan: regression test suite
Reviewers: rafael, lhames, loladiro
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D10144
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@238983 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
This was exposed by r238842 (which was reverted by r238900)
when doing a CMake build with -DBUILD_SHARED_LIBS=ON.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@238953 91177308-0d34-0410-b5e6-96231b3b80d8
llvm-rtdyld was relying on the default memory manager's EH frame registration,
which is host-dependent rather than target-dependent. As a result, big-endian
ELF Mips EH frames were being registered on OS X (and elsewhere). This is a
really bad idea.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@238951 91177308-0d34-0410-b5e6-96231b3b80d8
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@238941 91177308-0d34-0410-b5e6-96231b3b80d8
As the serialized debug map is becoming a first class citizen, a way
to cleanly dump it is required. We used -parse-only combined with
-v for that purpose before, but it dumps a lot of unrelated debug
stuff. Dumping the debug map was the only use of the -parse-only flag
anyway, so replace it with a more useful option.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@238940 91177308-0d34-0410-b5e6-96231b3b80d8
The ELF spec is very clear:
-----------------------------------------------------------------------------
If the value is non-zero, it represents a string table index that gives the
symbol name. Otherwise, the symbol table entry has no name.
--------------------------------------------------------------------------
In particular, a st_name of 0 most certainly doesn't mean that the symbol has
the same name as the section.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@238899 91177308-0d34-0410-b5e6-96231b3b80d8
In r233132 we started requiring a subcommand in llvm-cov, but this
made `llvm-cov --version` invalid, which is kind of silly. Print
version information in this case, as most people would expect.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@238897 91177308-0d34-0410-b5e6-96231b3b80d8
Doing so will allow us to also accept a YAML debug map in input as using
YAMLIO gives us the parsing for free. Being able to have textual debug
maps will in turn allow much more control over the tests, because 1/
no need to check-in a binary containing the debug map and 2/ it will allow
to use the same objects/IR files with made-up debug-maps to test
different scenari.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@238781 91177308-0d34-0410-b5e6-96231b3b80d8
Start using C++ types such as StringRef and MemoryBuffer in the C++ LTO
API. In doing so, clarify the ownership of the native object file: the caller
now owns it, not the LTOCodeGenerator. The C libLTO library has been modified
to use a derived class of LTOCodeGenerator that owns the object file.
Differential Revision: http://reviews.llvm.org/D10114
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@238776 91177308-0d34-0410-b5e6-96231b3b80d8
