This removes calls to isMaterializable in the following cases:
* It was redundant with a call to isDeclaration now that isDeclaration returns
the correct answer for materializable functions.
* It was followed by a call to Materialize. Just call Materialize and check EC.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221050 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This patch extends the 'show' and 'merge' commands in llvm-profdata to handle
sample PGO formats. Using the 'merge' command it is now possible to convert
one sample PGO format to another.
The only format that is currently not working is 'gcc'. I still need to
implement support for it in lib/ProfileData.
The changes in the sample profile support classes are needed for the
merge operation.
Reviewers: bogner
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D6065
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221032 91177308-0d34-0410-b5e6-96231b3b80d8
The getBinary and getBuffer method now return ordinary pointers of appropriate
const-ness. Ownership is transferred by calling takeBinary(), which returns a
pair of the Binary and a MemoryBuffer.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221003 91177308-0d34-0410-b5e6-96231b3b80d8
Do a better job classifying symbols. This increases the consistency
between the COFF handling code and the ELF side of things.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220952 91177308-0d34-0410-b5e6-96231b3b80d8
We're using cl::opt here, but for some reason we're reading out one
particular option by hand instead. This makes -help and the like
behave rather poorly, so let's not do it this way.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220928 91177308-0d34-0410-b5e6-96231b3b80d8
The also-emit-llvm option only supported getting the IR before optimizations.
This patch replaces it with a more generic save-temps option that saves the IR
both before and after optimizations.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220885 91177308-0d34-0410-b5e6-96231b3b80d8
I noticed that it was untested, and forcing it on caused some tests to fail:
LLVM :: Linker/metadata-a.ll
LLVM :: Linker/prefixdata.ll
LLVM :: Linker/type-unique-odr-a.ll
LLVM :: Linker/type-unique-simple-a.ll
LLVM :: Linker/type-unique-simple2-a.ll
LLVM :: Linker/type-unique-simple2.ll
LLVM :: Linker/type-unique-type-array-a.ll
LLVM :: Linker/unnamed-addr1-a.ll
LLVM :: Linker/visibility1.ll
If it is to be resurrected, it has to be fixed and we should probably have a
-preserve-source command line option in llvm-mc and run tests with and without
it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220741 91177308-0d34-0410-b5e6-96231b3b80d8
We used to always vectorize (slp and loop vectorize) in the LTO pass pipeline.
r220345 changed it so that we used the PassManager's fields 'LoopVectorize' and
'SLPVectorize' out of the desire to be able to disable vectorization using the
cl::opt flags 'vectorize-loops'/'slp-vectorize' which the before mentioned
fields default to.
Unfortunately, this turns off vectorization because those fields
default to false.
This commit adds flags to the LTO library to disable lto vectorization which
reconciles the desire to optionally disable vectorization during LTO and
the desired behavior of defaulting to enabled vectorization.
We really want tools to set PassManager flags directly to enable/disable
vectorization and not go the route via cl::opt flags *in*
PassManagerBuilder.cpp.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220652 91177308-0d34-0410-b5e6-96231b3b80d8
To do this, change the representation of lazy loaded functions.
The previous representation cannot differentiate between a function whose body
has been removed and one whose body hasn't been read from the .bc file. That
means that in order to drop a function, the entire body had to be read.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220580 91177308-0d34-0410-b5e6-96231b3b80d8
* Read modules lazily
* Don't treat the first file specially, instead merge all inputs into an empty
module.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220501 91177308-0d34-0410-b5e6-96231b3b80d8
This prints disassembly comments for Objective-C references to CFStrings,
Selectors, Classes and method calls.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220500 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This patch adds a new CMake build setting LLVM_BUILD_LLVM_DYLIB, which defaults to OFF. When set to ON, this will generate a shared library containing most of LLVM. The contents of the shared library can be overriden by specifying LLVM_DYLIB_COMPONENTS. LLVM_DYLIB_COMPONENTS can be set to a semi-colon delimited list of any LLVM components that you llvm-config can resolve.
On Windows, unless you are using Cygwin, you must specify an explicit symbol export file using LLVM_EXPORTED_SYMBOL_FILE. On Cygwin and all unix-like platforms if you do not specify LLVM_EXPORTED_SYMBOL_FILE, an export file containing only the LLVM C API will be auto-generated from the list of LLVM components specified in LLVM_DYLIB_COMPONENTS.
Reviewers: rnk
Reviewed By: rnk
Subscribers: rnk, llvm-commits
Differential Revision: http://reviews.llvm.org/D5890
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220490 91177308-0d34-0410-b5e6-96231b3b80d8
This tool lets us build LLVM components within the tree by setting up a
$GOPATH that resembles a tree fetched in the normal way with "go get".
It is intended that components such as the Go frontend will be built in-tree
using this tool.
Differential Revision: http://reviews.llvm.org/D5902
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220462 91177308-0d34-0410-b5e6-96231b3b80d8
I think it might make sense to make COFF::MaxNumberOfSections16 be a uint32_t, however, that may have wider-reaching implications in other projects, which is why I did not change that declaration.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220384 91177308-0d34-0410-b5e6-96231b3b80d8
This matches the behavior of GNU ar and also makes it easier to implemnt
support for the addlib command.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220336 91177308-0d34-0410-b5e6-96231b3b80d8
This is a micro optimization, but also makes the code a bit more flexible.
The MRIMembers variable is a short term hack. It is going away in the next
commit.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220334 91177308-0d34-0410-b5e6-96231b3b80d8
Don't duplicate names in comments and remove useless ones. Hopefully anyone
reading this knows what main is.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220298 91177308-0d34-0410-b5e6-96231b3b80d8
Revert "Correctly handle references to section symbols."
Revert "Allow forward references to section symbols."
Rui found a regression I am debugging.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220010 91177308-0d34-0410-b5e6-96231b3b80d8
llvm-symbolizer will consult one of the .dSYM paths passed via -dsym-hint
if it fails to find the .dSYM bundle at the default location.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220004 91177308-0d34-0410-b5e6-96231b3b80d8
When processing assembly like
.long .text
we were creating a new undefined symbol .text. GAS on the other hand would
handle that as a reference to the .text section.
This patch implements that by creating the section symbols earlier so that
they are visible during asm parsing.
The patch also updates llvm-readobj to print the symbol number in the relocation
dump so that the test can differentiate between two sections with the same name.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@219829 91177308-0d34-0410-b5e6-96231b3b80d8
I was quiet surprised to find this feature being used. Fortunately the uses
I found look fairly simple. In fact, they are just a very verbose version
of the regular ar commands.
Start implementing it then by parsing the script and setting the command
variables as if we had a regular command line.
This patch adds just enough support to create an empty archive and do a bit
of error checking. In followup patches I will implement at least addmod
and addlib.
From the description in the manual, even the more general case should not
be too hard to implement if needed. The features that don't map 1:1 to
the simple command line are
* Reading from multiple archives.
* Creating multiple archives.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@219521 91177308-0d34-0410-b5e6-96231b3b80d8
Long section names are represented as a slash followed by a numeric
ASCII string. This number is an offset into a string table.
Print the appropriate entry in the string table instead of the less
enlightening /4.
N.B. yaml2obj already does the right thing, this test exercises both
sides of the (de-)serialization.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@219458 91177308-0d34-0410-b5e6-96231b3b80d8
There are two methods in SectionRef that can fail:
* getName: The index into the string table can be invalid.
* getContents: The section might point to invalid contents.
Every other method will always succeed and returning and std::error_code just
complicates the code. For example, a section can have an invalid alignment,
but if we are able to get to the section structure at all and create a
SectionRef, we will always be able to read that invalid alignment.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@219314 91177308-0d34-0410-b5e6-96231b3b80d8
this, and in some circumstances (e.g. reducing particularly large test-cases)
this was causing bugpoint to be killed for hitting open file-handle limits.
No test case: I was only able to trigger this with test cases taking upwards of
10 mins to run.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@219244 91177308-0d34-0410-b5e6-96231b3b80d8
PE/COFF has a special section (.drectve) which can be used to pass options to
the linker (similar to LC_LINKER_OPTION). Add support to llvm-readobj to print
the contents of the section for tests.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@219228 91177308-0d34-0410-b5e6-96231b3b80d8
The plugin API doesn't have the notion of linkonce, only weak. It is up to the
plugin to figure out if a symbol used only for the symbol table can be dropped.
In particular, it has to avoid dropping a linkonce_odr selected by gold if there
is also a weak_odr.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@219188 91177308-0d34-0410-b5e6-96231b3b80d8
The call to copyAttributesFrom will copy the visibility, which might assert
if it were to produce something invalid like "internal hidden". We avoid it
by first creating the replacement with the original linkage and then setting
it to internal affter the call to copyAttributesFrom.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@219184 91177308-0d34-0410-b5e6-96231b3b80d8
When creating an internal function replacement for use in an alias we were
not remapping the argument uses in the instructions to point to the new
arguments.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@219177 91177308-0d34-0410-b5e6-96231b3b80d8
Codeview line tables for functions in different sections refer to a common
STRING_TABLE_SUBSECTION for filenames.
This happens when building with -Gy or with inline functions with MSVC.
Original patch by Jeff Muizelaar!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@219125 91177308-0d34-0410-b5e6-96231b3b80d8
This patch defines a new iterator for the imported symbols.
Make a change to COFFDumper to use that iterator to print
out imported symbols and its ordinals.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218915 91177308-0d34-0410-b5e6-96231b3b80d8
When the flag is given, the command prints out the COFF import table.
Currently only the import table directory will be printed.
I'm going to make another patch to print out the imported symbols.
The implementation of import directory entry iterator in
COFFObjectFile.cpp was buggy. This patch fixes that too.
http://reviews.llvm.org/D5569
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218891 91177308-0d34-0410-b5e6-96231b3b80d8
r206400 and r209442 added remarks that are disabled by default.
However, if a diagnostic handler is registered, the remarks are sent
unfiltered to the handler. This is the right behaviour for clang, since
it has its own filters.
However, the diagnostic handler exposed in the LTO API receives only the
severity and message. It doesn't have the information to filter by pass
name. For LTO, disabled remarks should be filtered by the producer.
I've changed `LLVMContext::setDiagnosticHandler()` to take a `bool`
argument indicating whether to respect the built-in filters. This
defaults to `false`, so other consumers don't have a behaviour change,
but `LTOCodeGenerator::setDiagnosticHandler()` sets it to `true`.
To make this behaviour testable, I added a `-use-diagnostic-handler`
command-line option to `llvm-lto`.
This fixes PR21108.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218784 91177308-0d34-0410-b5e6-96231b3b80d8
Users of getSectionContents shouldn't try to pass in BSS or virtual
sections. In all instances, this is a bug in the code calling this
routine.
N.B. Some COFF implementations (like CL) will mark their BSS sections as
taking space on disk. This would confuse COFFObjectFile into thinking
the section is larger than the file.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218549 91177308-0d34-0410-b5e6-96231b3b80d8
So in fully linked images when a call is made through a stub it now gets a
comment like the following in the disassembly:
callq 0x100000f6c ## symbol stub for: _printf
indicating the call is to a symbol stub and which symbol it is for. This is
done for branch reference types and seeing if the branch target is in a stub
section and if so using the indirect symbol table entry for that stub and
using that symbol table entries symbol name.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218546 91177308-0d34-0410-b5e6-96231b3b80d8
files in this directory. If it should be defined anywhere, it should be defined
when building lib/LTO/LTOCodeGenerator.cpp, but we've not had it defined there
for quite some time, so that doesn't really seem to be very important. (It also
would slow down the modules build by creating extra module variants.)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218544 91177308-0d34-0410-b5e6-96231b3b80d8
get the literal string “Hello world” printed as a comment on the instruction
that loads the pointer to it. For now this is just for x86_64. So for object
files with relocation entries it produces things like:
leaq L_.str(%rip), %rax ## literal pool for: "Hello world\n"
and similar for fully linked images like executables:
leaq 0x4f(%rip), %rax ## literal pool for: "Hello world\n"
Also to allow testing against darwin’s otool(1), I hooked up the existing
-no-show-raw-insn option to the Mach-O parser code, added the new Mach-O
only -full-leading-addr option to match otool(1)'s printing of addresses and
also added the new -print-imm-hex option.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218423 91177308-0d34-0410-b5e6-96231b3b80d8
This patch removes the old JIT memory manager (which does not provide any
useful functionality now that the old JIT is gone), and migrates the few
remaining clients over to SectionMemoryManager.
http://llvm.org/PR20848
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218316 91177308-0d34-0410-b5e6-96231b3b80d8
This splits the logic for actually looking up coverage information
from the logic that displays it. These were tangled rather thoroughly
so this change is a bit large, but it mostly consists of moving things
around. The coverage lookup logic itself now lives in the library,
rather than being spread between the library and the tool.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218184 91177308-0d34-0410-b5e6-96231b3b80d8
This debug output is really for testing CoverageMappingReader, not the
llvm-cov tool. Move it to where it can be more useful.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218183 91177308-0d34-0410-b5e6-96231b3b80d8
Having create* functions return the object they create is more
readable than using an in-out parameter.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218139 91177308-0d34-0410-b5e6-96231b3b80d8
Uncovered lines in the middle of a covered region weren't being shown
when filtering to a particular function.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218109 91177308-0d34-0410-b5e6-96231b3b80d8
The filename-equivalence flag allows you to show coverage when your
source files don't have the same full paths as those that generated
the data. This is mostly useful for writing tests in a cross-platform
way.
This wasn't triggering in cases where the filename was derived
directly from the coverage data, which meant certain types of test
case were impossible to write. This patch fixes that, and following
patches involve tests that need this.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218108 91177308-0d34-0410-b5e6-96231b3b80d8
This format is simply a regular object file with the bitcode stored in a
section named ".llvmbc", plus any number of other (non-allocated) sections.
One immediate use case for this is to accommodate compilation processes
which expect the object file to contain metadata in non-allocated sections,
such as the ".go_export" section used by some Go compilers [1], although I
imagine that in the future we could consider compiling parts of the module
(such as large non-inlinable functions) directly into the object file to
improve LTO efficiency.
[1] http://golang.org/doc/install/gccgo#Imports
Differential Revision: http://reviews.llvm.org/D4371
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218078 91177308-0d34-0410-b5e6-96231b3b80d8
- Replace std::unordered_map with DenseMap
- Use std::pair instead of manually combining two unsigneds
- Assert if insert is called with invalid arguments
- Avoid an unnecessary copy of a std::vector
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218074 91177308-0d34-0410-b5e6-96231b3b80d8
As suggested by David Blaikie, this may be easier to read.
The original warning was:
../tools/llvm-cov/llvm-cov.cpp:53:49: error: ISO C++ forbids zero-size array 'argv' [-Werror=pedantic]
std::string Invocation(std::string(argv[0]) + " " + argv[1]);
It seems to be the case that GCC's warning gets confused and thinks
'argv' is a declaration here. GCC bugzilla issue #61259.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218048 91177308-0d34-0410-b5e6-96231b3b80d8
This encapsulates how we handle the coverage regions of a file or
function. In the old model, the user had to deal with nested regions,
so they needed to maintain their own auxiliary data structures to get
any useful information out of this. The new API provides a sequence of
non-overlapping coverage segments, which makes it possible to render
coverage information in a single pass and avoids a fair amount of
extra work.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@217975 91177308-0d34-0410-b5e6-96231b3b80d8
It isn't always useful to skip blank lines, as evidenced by the
somewhat awkward use of line_iterator in llvm-cov. This adds a knob to
control whether or not to skip blanks.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@217960 91177308-0d34-0410-b5e6-96231b3b80d8
SourceCoverageView currently has "Kind" and a list of child views, all
of which must have either an expansion or an instantiation Kind. In
addition to being an error-prone design, this makes it awkward to
differentiate between the two child types and adds a number of
optionally used members to the type.
Split the subview types into their own separate objects, and maintain
lists of each rather than one combined "Children" list.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@217940 91177308-0d34-0410-b5e6-96231b3b80d8
First step done in this commit is to get flush out enough of the
SymbolizerGetOpInfo() routine to symbolic an X86_64 hello world .o and
its loading of the literal string and call to printf. Also the code to
symbolicate the X86_64_RELOC_SUBTRACTOR relocation and a test is also
added to show a slightly more complicated case.
Next will be to flush out enough of SymbolizerSymbolLookUp() to get the
literal string “Hello world” printed as a comment on the instruction that load
the pointer to it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@217893 91177308-0d34-0410-b5e6-96231b3b80d8
Offset is a terrible name for an indentation / nesting level, and it
confuses me every time I look at this code.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@217861 91177308-0d34-0410-b5e6-96231b3b80d8
Teach yaml2obj how to make a bigobj COFF file. Like the rest of LLVM,
we automatically decide whether or not to use regular COFF or bigobj
COFF on the fly depending on how many sections the resulting object
would have.
This ends the task of adding bigobj support to LLVM.
N.B. This was tested by forcing yaml2obj to be used in bigobj mode
regardless of the number of sections. While a dedicated test was
written, the smallest I could make it was 36 MB (!) of yaml and it still
took a significant amount of time to execute on a powerful machine.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@217858 91177308-0d34-0410-b5e6-96231b3b80d8
This finishes the ability of llvm-objdump to print out all information from
the LC_DYLD_INFO load command.
The -bind option prints out symbolic references that dyld must resolve
immediately.
The -lazy-bind option prints out symbolc reference that are lazily resolved on
first use.
The -weak-bind option prints out information about symbols which dyld must
try to coalesce across images.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@217853 91177308-0d34-0410-b5e6-96231b3b80d8
This changes the debug output of the llvm-cov tool to consistently
write to stderr, and moves the highlighting output closer to where
it's relevant.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@217838 91177308-0d34-0410-b5e6-96231b3b80d8
In r217746, though it was supposed to be NFC, I broke llvm-cov's
handling of showing regions without showing counts. This should've
shown up in the existing tests, except they were checking debug output
that was displayed regardless of what was actually output. I've moved
the relevant debug output to a more appropriate place so that the
tests catch this kind of thing.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@217835 91177308-0d34-0410-b5e6-96231b3b80d8
Teach WinCOFFObjectWriter how to write -mbig-obj style object files;
these object files allow for more sections inside an object file.
Our support for BigObj is notably different from binutils and cl: we
implicitly upgrade object files to BigObj instead of asking the user to
compile the same file *again* but with another flag. This matches up
with how LLVM treats ELF variants.
This was tested by forcing LLVM to always emit BigObj files and running
the entire test suite. A specific test has also been added.
I've lowered the maximum number of sections in a normal COFF file,
VS "14" CTP 3 supports no more than 65279 sections. This is important
otherwise we might not switch to BigObj quickly enough, leaving us with
a COFF file that we couldn't link.
yaml2obj support is all that remains to implement.
Differential Revision: http://reviews.llvm.org/D5349
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@217812 91177308-0d34-0410-b5e6-96231b3b80d8
This removes the need to pass a starting and ending line when creating
a SourceCoverageView, since these are easy to determine.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@217746 91177308-0d34-0410-b5e6-96231b3b80d8
A single function in SourceCoverageDataManager was the only user of
some of the comparisons in CounterMappingRegion, and at this point we
know that only one file is relevant. This lets us use slightly simpler
logic directly in the client.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@217745 91177308-0d34-0410-b5e6-96231b3b80d8
Similar to my previous -exports-trie option, the -rebase option dumps info from
the LC_DYLD_INFO load command. The rebasing info is a list of the the locations
that dyld needs to adjust if a mach-o image is not loaded at its preferred
address. Since ASLR is now the default, images almost never load at their
preferred address, and thus need to be rebased by dyld.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@217709 91177308-0d34-0410-b5e6-96231b3b80d8
This fixes a call to sys::fs::equivalent that should've been to
CodeCoverageTool::equivalentFiles, which lets us restore the test of
r217476 that was removed in r217478.
This reverts r217478, but the test works this time.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@217646 91177308-0d34-0410-b5e6-96231b3b80d8
With this a DataLayoutPass can be reused for multiple modules.
Once we have doInitialization/doFinalization, it doesn't seem necessary to pass
a Module to the constructor.
Overall this change seems in line with the idea of making DataLayout a required
part of Module. With it the only way of having a DataLayout used is to add it
to the Module.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@217548 91177308-0d34-0410-b5e6-96231b3b80d8
This adds support for reading the "bigobj" variant of COFF produced by
cl's /bigobj and mingw's -mbig-obj.
The most significant difference that bigobj brings is more than 2**16
sections to COFF.
bigobj brings a few interesting differences with it:
- It doesn't have a Characteristics field in the file header.
- It doesn't have a SizeOfOptionalHeader field in the file header (it's
only used in executable files).
- Auxiliary symbol records have the same width as a symbol table entry.
Since symbol table entries are bigger, so are auxiliary symbol
records.
Write support will come soon.
Differential Revision: http://reviews.llvm.org/D5259
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@217496 91177308-0d34-0410-b5e6-96231b3b80d8
This is the plugin version of pr20882.
This handles the case of every common symbol being in the IR. We will need some
support from gold to handle the case where some symbols are in ELF and some in
the IR.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@217458 91177308-0d34-0410-b5e6-96231b3b80d8
llvm-cov had a SourceRange type that was nearly identical to a
CountedRegion except that it shaved off a couple of fields. There
aren't likely to be enough of these for the minor memory savings to be
worth the extra complexity here.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@217417 91177308-0d34-0410-b5e6-96231b3b80d8
This name was too similar to CoverageMappingRegion, and the type
really belongs in the coverage library anyway.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@217416 91177308-0d34-0410-b5e6-96231b3b80d8
FunctionCoverageMapping::PrettyName was from a version of the tool
during review, and isn't actually used currently.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@217398 91177308-0d34-0410-b5e6-96231b3b80d8
This adds the printing of more load commands, so that the normal load commands
in a typical X86 Mach-O executable can all be printed.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@217172 91177308-0d34-0410-b5e6-96231b3b80d8
sections.
This allows fine-grained control of the memory layout of hypothetical target
processes for testing purposes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@217122 91177308-0d34-0410-b5e6-96231b3b80d8
The basic idea is similar to the existing cross compilation support. A directory must be configured to build host versions of tablegen tools and llvm-config. This directory can be user provided (and configured), or it can be created during the build. During a build the native build directory will be configured and built to supply the tablegen tools used during the build. A user could also explicitly provide the tablegen executables to run on the CMake command line.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@217105 91177308-0d34-0410-b5e6-96231b3b80d8
I took a guess at the changes to the gold plugin, because that doesn't
seem to build by default for me. Not sure what dependencies I might be
missing for that.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@217056 91177308-0d34-0410-b5e6-96231b3b80d8
This forces callers to use std::move when calling it. It is somewhat odd to have
code with std::move that doesn't always move, but it is also odd to have code
without std::move that sometimes moves.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@217049 91177308-0d34-0410-b5e6-96231b3b80d8
This CL replaces the constant DarwinX86AsmBackend.PushInstrSize with a method
that lets the backend account for different sizes of "push %reg" instruction
sizes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@217020 91177308-0d34-0410-b5e6-96231b3b80d8
The code is buggy and barely tested. It is also mostly boilerplate.
(This includes MCObjectDisassembler, which is the interface to that
functionality)
Following an IRC discussion with Jim Grosbach, it seems sensible to just
nuke the whole lot of functionality, and dig it up from VCS if
necessary (I hope not!).
All of this stuff appears to have been added in a huge patch dump (look
at the timeframe surrounding e.g. r182628) where almost every patch
seemed to be untested and not reviewed before being committed.
Post-review responses to the patches were never addressed. I don't think
any of it would have passed pre-commit review.
I doubt anyone is depending on this, since this code appears to be
extremely buggy. In limited testing that Michael Spencer and I did, we
couldn't find a single real-world object file that wouldn't crash the
CFG reconstruction stuff. The symbolizer stuff has O(n^2) behavior and
so is not much use to anyone anyway. It seemed simpler to remove them as
a whole. Most of this code is boilerplate, which is the only way it was
able to scrape by 60% coverage.
HEADSUP: Modules folks, some files I nuked were referenced from
include/llvm/module.modulemap; I just deleted the references. Hopefully
that is the right fix (one was a FIXME though!).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@216983 91177308-0d34-0410-b5e6-96231b3b80d8
Approved by Jim Grosbach, Lang Hames, Rafael Espindola.
This reinstates commits r215111, 215115, 215116, 215117, 215136.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@216982 91177308-0d34-0410-b5e6-96231b3b80d8
This allows streams that only use BLOCKINFO for debugging purposes to omit
the block entirely. As long as another stream is available with the correct
BLOCKINFO, the first stream can still be analyzed and dumped.
As part of this commit, BitstreamReader gets a move constructor and move
assignment operator, as well as a takeBlockInfo method.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@216826 91177308-0d34-0410-b5e6-96231b3b80d8
MachOObjectFile in lib/Object currently has no support for parsing the rebase,
binding, and export information from the LC_DYLD_INFO load command in final
linked mach-o images. This patch adds support for parsing the exports trie data
structure. It also adds an option to llvm-objdump to dump that export info.
I did the exports parsing first because it is the hardest. The information is
encoded in a trie structure, but the standard ObjectFile way to inspect content
is through iterators. So I needed to make an iterator that would do a
non-recursive walk through the trie and maintain the concatenation of edges
needed for the current string prefix.
I plan to add similar support in MachOObjectFile and llvm-objdump to
parse/display the rebasing and binding info too.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@216808 91177308-0d34-0410-b5e6-96231b3b80d8
This adds the printing of the LC_SEGMENT load command and sections,
LC_SYMTAB and LC_DYSYMTAB load commands.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@216795 91177308-0d34-0410-b5e6-96231b3b80d8
By taking a reference we can do the ownership transfer in one place instead of
expecting every caller to do it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@216492 91177308-0d34-0410-b5e6-96231b3b80d8
The attached patch simplifies a few interfaces that don't need to take
ownership of a buffer.
For example, both parseAssembly and parseBitcodeFile will parse the
entire buffer before returning. There is no need to take ownership.
Using a MemoryBufferRef makes it obvious in the type signature that
there is no ownership transfer.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@216488 91177308-0d34-0410-b5e6-96231b3b80d8
Long term the idea if for the engine to not own the buffers, but for now
this is consistent with the rest of the API.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@216484 91177308-0d34-0410-b5e6-96231b3b80d8
The memory management in BugPoint is fairly convoluted, so this just unwraps
one layer by changing the return type of functions that always return
owned Modules.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@216464 91177308-0d34-0410-b5e6-96231b3b80d8
Take a StringRef instead of a "const char *".
Take a "std::error_code &" instead of a "std::string &" for error.
A create static method would be even better, but this patch is already a bit too
big.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@216393 91177308-0d34-0410-b5e6-96231b3b80d8
The switch statement would never fire due to the preceding break statement. Also, the switch statement has a default label with no case labels. Simplified the code, and allow it to execute.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@216346 91177308-0d34-0410-b5e6-96231b3b80d8
There are two parts to this. First, the plugin needs to tell gold the comdat by
setting comdat_key.
What gets things a bit more complicated is that gold only seems
symbols. In particular, if A is an alias to B, it only sees the symbols
A and B. It can then ask us to keep symbol A but drop symbol B. What
we have to do instead is to create an internal version of B and make A
an alias to that.
At some point some of this logic should be moved to lib/Linker so that
we don't map a Constant to an internal version just to have lib/Linker
map that again to the destination module.
The reason for implementing this in tools/gold for now is simplicity.
With it in place it should be possible to update clang to use comdats
for constructors and destructors on ELF without breaking the LTO
bootstrap. Once that is done I intend to come back and improve the
interface lib/Linker exposes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@216302 91177308-0d34-0410-b5e6-96231b3b80d8
This commit expands llvm-cov's functionality by adding support for a new code coverage
tool that uses LLVM's coverage mapping format and clang's instrumentation based profiling.
The gcov compatible tool can be invoked by supplying the 'gcov' command as the first argument,
or by modifying the tool's name to end with 'gcov'.
Differential Revision: http://reviews.llvm.org/D4445
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@216300 91177308-0d34-0410-b5e6-96231b3b80d8
There is a fundamental difference between how the gold API and lib/LTO view
the LTO process.
The gold API talks about a particular symbol in a particular file. The lib/LTO
API talks about a symbol in the merged module.
The merged module is then defined in terms of the IR semantics. In particular,
a linkonce_odr GV is only copied if it is used, since it is valid to drop
unused linkonce_odr GVs.
In the testcase in pr19901 both properties collide. What happens is that gold
asks us to keep a particular linkonce_odr symbol, but the IR linker doesn't
copy it to the merged module and we never have a chance to ask lib/LTO to keep
it.
This patch fixes it by having a more direct implementation of the gold API. If
it asks us to keep a symbol, we change the linkage so it is not linkonce. If it
says we can drop a symbol, we do so. All of this before we even send the module
to lib/Linker.
Since now we don't have to produce LTO_SYMBOL_SCOPE_DEFAULT_CAN_BE_HIDDEN,
during symbol resolution we can use a temporary LLVMContext and do lazy
module loading. This allows us to keep the minimum possible amount of
allocated memory around. This should also allow as much parallelism as
we want, since there is no shared context.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@216215 91177308-0d34-0410-b5e6-96231b3b80d8
Implement `uselistorder` and `uselistorder_bb` assembly directives,
which allow the use-list order to be recovered when round-tripping to
assembly.
This is the bulk of PR20515.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@216025 91177308-0d34-0410-b5e6-96231b3b80d8
Owning the buffer is somewhat inflexible. Some Binaries have sub Binaries
(like Archive) and we had to create dummy buffers just to handle that. It is
also a bad fit for IRObjectFile where the Module wants to own the buffer too.
Keeping this ownership would make supporting IR inside native objects
particularly painful.
This patch focuses in lib/Object. If something elsewhere used to own an Binary,
now it also owns a MemoryBuffer.
This patch introduces a few new types.
* MemoryBufferRef. This is just a pair of StringRefs for the data and name.
This is to MemoryBuffer as StringRef is to std::string.
* OwningBinary. A combination of Binary and a MemoryBuffer. This is needed
for convenience functions that take a filename and return both the
buffer and the Binary using that buffer.
The C api now uses OwningBinary to avoid any change in semantics. I will start
a new thread to see if we want to change it and how.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@216002 91177308-0d34-0410-b5e6-96231b3b80d8
* Use StringRef instead of std::string&
* Return a std::unique_ptr<Module> instead of taking an optional module to write
to (was not really used).
* Use current comment style.
* Use current naming convention.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215989 91177308-0d34-0410-b5e6-96231b3b80d8
Call `verifyModule()` after parsing and after every transformation.
Also convert some `DEBUG(dbgs())` to `errs()` to increase visibility
into what's going on.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215951 91177308-0d34-0410-b5e6-96231b3b80d8
file with -macho, the Mach-O specific object file parser option.
After some discussion I chose to do this implementation contained in the logic
of llvm-objdump’s MachODump.cpp using a second disassembler for thumb when
needed and with updates mostly contained in the MachOObjectFile class.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215931 91177308-0d34-0410-b5e6-96231b3b80d8
Add header guards to files that were missing guards. Remove #endif comments
as they don't seem common in LLVM (we can easily add them back if we decide
they're useful)
Changes made by clang-tidy with minor tweaks.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215558 91177308-0d34-0410-b5e6-96231b3b80d8
ARM bots (& others, I think, now that I look) were failing because we
were using incorrect printf-style format specifiers. They were wrong
on almost any platform, actually, just mostly harmlessly so.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215196 91177308-0d34-0410-b5e6-96231b3b80d8
be deleted. This will be reapplied as soon as possible and before
the 3.6 branch date at any rate.
Approved by Jim Grosbach, Lang Hames, Rafael Espindola.
This reverts commits r215111, 215115, 215116, 215117, 215136.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215154 91177308-0d34-0410-b5e6-96231b3b80d8
I am sure we will be finding bits and pieces of dead code for years to
come, but this is a good start.
Thanks to Lang Hames for making MCJIT a good replacement!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215111 91177308-0d34-0410-b5e6-96231b3b80d8
Also make the disassembler created with the Mach-O parser (the -m option)
pick up the Target specific attributes specified with -mattr option.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215032 91177308-0d34-0410-b5e6-96231b3b80d8
mode.
This will cause -verify mode to report failure when RuntimeDyld encounters an
internal error (e.g. overflows in relocation computations). Previously we had
let these errors slip past unreported.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214925 91177308-0d34-0410-b5e6-96231b3b80d8
This is mostly a cleanup, but it changes a fairly old behavior.
Every "real" LTO user was already disabling the silly internalize pass
and creating the internalize pass itself. The difference with this
patch is for "opt -std-link-opts" and the C api.
Now to get a usable behavior out of opt one doesn't need the funny
looking command line:
opt -internalize -disable-internalize -internalize-public-api-list=foo,bar -std-link-opts
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214919 91177308-0d34-0410-b5e6-96231b3b80d8
Updated `verify-uselistorder` to more than double the number of use-list
orders it checks.
- Every time it verifies an order, it then reverses the order and
verifies again.
- It now verifies the initial order, before running any shuffles.
Changed the default to `-num-shuffles=1`, since this is already four
checks, and after r214584 shuffling is guaranteed to make a new order.
This is part of PR5680.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214596 91177308-0d34-0410-b5e6-96231b3b80d8
`shuffleUseLists()` is only used in `verify-uselistorder`, so move it
there to avoid bloating other executables. As a drive-by, update some
of the header docs.
This is part of PR5680.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214592 91177308-0d34-0410-b5e6-96231b3b80d8
Also fix the error handling. No testcaes, issue found by inspection.
Thanks to David Blaikie for the suggestion.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214535 91177308-0d34-0410-b5e6-96231b3b80d8
Instead of moving out the data in a ErrorOr<std::unique_ptr<Foo>>, get
a reference to it.
Thanks to David Blaikie for the suggestion.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214516 91177308-0d34-0410-b5e6-96231b3b80d8
"Create a default symver on Linux like ELF OSes."
Fails the build under Debian with ld.gold:
/usr/bin/ld.gold: --default-symver: unknown option
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214482 91177308-0d34-0410-b5e6-96231b3b80d8
Change the default for `-num-shuffles` to 5 and better document the
algorithm in the header docs of `verify-uselistorder`.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214419 91177308-0d34-0410-b5e6-96231b3b80d8
Turns out `parseBitcodeFile()` does *not* take ownership of the buffer.
This was already clear in the header docs, but I obviously didn't read
them (having noticed that it gets stored in a `unique_ptr<>`).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214313 91177308-0d34-0410-b5e6-96231b3b80d8
use in -verify mode.
This patch adds three hidden command line options to llvm-rtdyld:
-target-addr-start <start-addr> : Specify the start of the virtual address
space on the phony target.
-target-addr-end <end-addr> : Specify the end of the virtual address space
on the phony target.
-target-section-sep <sep> : Specify the separation (in bytes) between the
end of one section and the start of the next.
These options automatically default to sane values for the target platform. In
particular, they allow narrow (e.g. 32-bit, 16-bit) targets to be tested from
wider (e.g. 64-bit, 32-bit) hosts without overflowing pointers.
The section separation option defaults to zero, but can be set to a large number
(e.g. 1 << 32) to force large separations between sections in order to
stress-test large-code-model code.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214255 91177308-0d34-0410-b5e6-96231b3b80d8
Predict and serialize use-list order in bitcode. This makes the option
`-preserve-bc-use-list-order` work *most* of the time, but this is still
experimental.
- Builds a full value-table up front in the writer, sets up a list of
use-list orders to write out, and discards the table. This is a
simpler first step than determining the order from the various
overlapping IDs of values on-the-fly.
- The shuffles stored in the use-list order list have an unnecessarily
large memory footprint.
- `blockaddress` expressions cause functions to be materialized
out-of-order. For now I've ignored this problem, so use-list orders
will be wrong for constants used by functions that have block
addresses taken. There are a couple of ways to fix this, but I
don't have a concrete plan yet.
- When materializing functions lazily, the use-lists for constants
will not be correct. This use case is out of scope: what should the
use-list order be, if it's incomplete?
This is part of PR5680.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214125 91177308-0d34-0410-b5e6-96231b3b80d8
The gcov compatible code is moved to its own file and
llvm-cov is updated to be a wrapper that always calls
the gcov main function.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214107 91177308-0d34-0410-b5e6-96231b3b80d8
Ugh. Turns out not even transformation passes link in how to read IR.
I sincerely believe the buildbots will finally agree with my system
after this though. (I don't really understand why all of this has been
working on my system, but not on all the buildbots.)
Create a new tool called llvm-uselistorder to use for verifying use-list
order. For now, just dump everything from the (now defunct)
-verify-use-list-order pass into the tool.
This might be a better way to test use-list order anyway.
Part of PR5680.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213957 91177308-0d34-0410-b5e6-96231b3b80d8
