Unwind info contents were indented at the same level as function table
contents. That's a bit confusing because the unwind info is pointed by
function table. In other places we usually increment indentation depth
by one when dereferncing a pointer.
This patch also removes extraneous newlines between function tables.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202879 91177308-0d34-0410-b5e6-96231b3b80d8
PassInfo structures of the legacy pass manager. Also give it the Legacy
prefix as it is not a particularly widely used header.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202839 91177308-0d34-0410-b5e6-96231b3b80d8
directly care about the Value class (it is templated so that the key can
be any arbitrary Value subclass), it is in fact concretely tied to the
Value class through the ValueHandle's CallbackVH interface which relies
on the key type being some Value subclass to establish the value handle
chain.
Ironically, the unittest is already in the right library.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202824 91177308-0d34-0410-b5e6-96231b3b80d8
The original code does not work correctly on executable files because the
code is written in such a way that only object files are assumed to be given
to llvm-objdump.
Contents of RuntimeFunction are different between executables and objects. In
executables, fields in RuntimeFunction have actual addresses to unwind info
structures. On the other hand, in object files, the fields have zero value,
but instead there are relocations pointing to the fields, so that Linker will
fill them at link-time.
So, when we are reading an object file, we need to use relocation info to
find the location of unwind info. When executable, we should just look at the
values in RuntimeFunction.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202785 91177308-0d34-0410-b5e6-96231b3b80d8
The shared library generated by autoconf will now be called
libLLVM-$(VERSION_MAJOR).$(VERSION_MINOR).$(VERSION_PATCH)$(VERSION_SUFFIX).so
and a symlink named
libLLVM-$(VERSION_MAJOR).$(VERSION_MINOR)$(VERSION_SUFFIX).so will
also be created in the install directory.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202720 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Previously llvm-config --system-libs would print something like:
$ llvm-config --system-libs
-lz -ltinfo -lrt -ldl -lm
Now we don't emit blank line. Functionality is unchanged otherwise, in
particular llvm-config --libs --system-libs still emits the LLVM libraries
and the system libraries on different lines.
Reviewers: chapuni
Reviewed By: chapuni
CC: llvm-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D2901
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202719 91177308-0d34-0410-b5e6-96231b3b80d8
This centralizes the Makefile handling of -install_name and -rpath. It also
moves the cmake build to using @rpath. The reason being that libclang needs it,
and it works for everything else.
A followup patch will move clang to using this and then there will be a single
point to edit to support other systems.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202499 91177308-0d34-0410-b5e6-96231b3b80d8
The current COFF unwind printer tries to print SEH handler function names,
assuming that it can always find function names in string table. It crashes
if file being read has no symbol table (i.e. executable).
With this patch, llvm-objdump prints SEH handler's RVA if there's no symbol
table entry for that RVA.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202466 91177308-0d34-0410-b5e6-96231b3b80d8
Eventually DataLayoutPass should go away, but for now that is the only easy
way to get a DataLayout in some APIs. This patch only changes the ones that
have easy access to a Module.
One interesting issue with sometimes using DataLayoutPass and sometimes
fetching it from the Module is that we have to make sure they are equivalent.
We can get most of the way there by always constructing the pass with a Module.
In fact, the pass could be changed to point to an external DataLayout instead
of owning one to make this stricter.
Unfortunately, the C api passes a DataLayout, so it has to be up to the caller
to make sure the pass and the module are in sync.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202204 91177308-0d34-0410-b5e6-96231b3b80d8
Now that DataLayout is not a pass, store one in Module.
Since the C API expects to be able to get a char* to the datalayout description,
we have to keep a std::string somewhere. This patch keeps it in Module and also
uses it to represent modules without a DataLayout.
Once DataLayout is mandatory, we should probably move the string to DataLayout
itself since it won't be necessary anymore to represent the special case of a
module without a DataLayout.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202190 91177308-0d34-0410-b5e6-96231b3b80d8
Instead, have a DataLayoutPass that holds one. This will allow parts of LLVM
don't don't handle passes to also use DataLayout.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202168 91177308-0d34-0410-b5e6-96231b3b80d8
boundaries.
It is possible to create an ELF executable where symbol from say .text
section 'points' to the address outside the section boundaries. It does
not have a sense to disassemble something outside the section.
Without this fix llvm-objdump prints finite or infinite (depends on
the executable file architecture) number of 'invalid instruction
encoding' warnings.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202083 91177308-0d34-0410-b5e6-96231b3b80d8
After this I will set the default back to F_None. The advantage is that
before this patch forgetting to set F_Binary would corrupt a file on windows.
Forgetting to set F_Text produces one that cannot be read in notepad, which
is a better failure mode :-)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202052 91177308-0d34-0410-b5e6-96231b3b80d8
The LLVMSupport library implementation consolidates all dependencies on
system libraries. Move the logic gathering system libraries out of
'cmake/modules/LLVM-Config.cmake' and into 'lib/Support/CMakeLists.txt'.
Use the target_link_libraries() command there to tell CMake about the
link dependencies of the LLVMSupport implementation. CMake will
automatically propagate this to all targets that link LLVMSupport
directly or indirectly.
We still need to build knowledge of system library dependencies into
'llvm-config'. Store the list of libraries needed in a property on
LLVMSupport and teach 'tools/llvm-config/CMakeLists.txt' to retrieve it
from there.
Drop all calls to 'link_system_libs' and 'get_system_libs' from our
CMake code. Replace their implementations with a warning that explains
the calls are no longer necessary. Also drop from 'LLVMConfig.cmake'
the HAVE_* and related variables that were published there only to allow
'get_system_libs' to run outside our build process.
Contributed by Brad King.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201969 91177308-0d34-0410-b5e6-96231b3b80d8
CodeGenPrepare uses extensively TargetLowering which is part of libLLVMCodeGen.
This is a layer violation which would introduce eventually a dependence on
CodeGen in ScalarOpts.
Move CodeGenPrepare into libLLVMCodeGen to avoid that.
Follow-up of <rdar://problem/15519855>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201912 91177308-0d34-0410-b5e6-96231b3b80d8
This interface allows IRObjectFile to be implemented without having dummy
methods for all section and segment related methods.
Both llvm-ar and llvm-nm are changed to use it. Unfortunately the mangler is
still not plugged in since it requires some refactoring to make a Module hold
a DataLayout.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201881 91177308-0d34-0410-b5e6-96231b3b80d8
This replaces the old NoIntegratedAssembler with at TargetOption. This is
more flexible and will be used to forward clang's -no-integrated-as option.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201836 91177308-0d34-0410-b5e6-96231b3b80d8
The SuppressWarnings flag, unfortunately, isn't very useful for custom tools
that want to use the LLVM module linker. So I'm changing it to a parameter of
the Linker, and the flag itself moves to the llvm-link tool.
For the time being as SuppressWarnings is pretty much the only "option" it
seems reasonable to propagate it to Linker objects. If we end up with more
options in the future, some sort of "struct collecting options" may be a
better idea.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201819 91177308-0d34-0410-b5e6-96231b3b80d8
SEH table addresses are VA in COFF file. In this patch we convert VA to RVA
before printing it, because dumpbin prints them as RVAs.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201760 91177308-0d34-0410-b5e6-96231b3b80d8
The same code (~20 lines) for initializing a TargetOptions object from CodeGen
cmdline flags is duplicated 4 times in 4 different tools. This patch moves it
into a utility function.
Since the CodeGen/CommandFlags.h file defines cl::opt flags in a header, it's
a bit of a touchy situation because we should only link them into tools. So this
patch puts the init function in the header.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201699 91177308-0d34-0410-b5e6-96231b3b80d8
Load Configuration Table may contain a pointer to SEH table. This patch is to
print the offset to the table. Printing SEH table contents is a TODO.
The layout of Layout Configuration Table is described in Microsoft PE/COFF
Object File Format Spec, but the table's offset/size descriptions seems to be
totally wrong, at least in revision 8.3 of the spec. I believe the table in
this patch is the correct one.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201638 91177308-0d34-0410-b5e6-96231b3b80d8
In gcov, the -o flag can accept either a directory or a file name.
When given a directory, the gcda and gcno files are expected to be in
that directory. When given a file, the gcda and gcno files are
expected to be named based on the stem of that file. Non-existent
paths are treated as files.
This implements compatible behaviour.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201555 91177308-0d34-0410-b5e6-96231b3b80d8
Introducing llvm-profdata, a tool for merging profile data generated by
PGO instrumentation in clang.
- The name indicates a file extension of <name>.profdata. Eventually
profile data output by clang should be changed to that extension.
- llvm-profdata merges two profiles. However, the name is more general,
since it will likely pick up more tasks (such as summarizing a single
profile).
- llvm-profdata parses the current text-based format, but will be
updated once we settle on a binary format.
<rdar://problem/15949645>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201535 91177308-0d34-0410-b5e6-96231b3b80d8
It was pointing to lib\clang\3.4, but now we're on 3.5.
Make CMake insert the right version automatically.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201363 91177308-0d34-0410-b5e6-96231b3b80d8
