The motivation behind this patch is that future directions require us to
be able to compute the hash value of records independently of actually
using them for de-duplication.
The current structure of TypeSerializer / TypeTableBuilder being a
single entry point that takes an unserialized type record, and then
hashes and de-duplicates it is not flexible enough to allow this.
At the same time, the existing TypeSerializer is already extremely
complex for this very reason -- it tries to be too many things. In
addition to serializing, hashing, and de-duplicating, ti also supports
splitting up field list records and adding continuations. All of this
functionality crammed into this one class makes it very complicated to
work with and hard to maintain.
To solve all of these problems, I've re-written everything from scratch
and split the functionality into separate pieces that can easily be
reused. The end result is that one class TypeSerializer is turned into 3
new classes SimpleTypeSerializer, ContinuationRecordBuilder, and
TypeTableBuilder, each of which in isolation is simple and
straightforward.
A quick summary of these new classes and their responsibilities are:
- SimpleTypeSerializer : Turns a non-FieldList leaf type into a series of
bytes. Does not do any hashing. Every time you call it, it will
re-serialize and return bytes again. The same instance can be re-used
over and over to avoid re-allocations, and in exchange for this
optimization the bytes returned by the serializer only live until the
caller attempts to serialize a new record.
- ContinuationRecordBuilder : Turns a FieldList-like record into a series
of fragments. Does not do any hashing. Like SimpleTypeSerializer,
returns references to privately owned bytes, so the storage is
invalidated as soon as the caller tries to re-use the instance. Works
equally well for LF_FIELDLIST as it does for LF_METHODLIST, solving a
long-standing theoretical limitation of the previous implementation.
- TypeTableBuilder : Accepts sequences of bytes that the user has already
serialized, and inserts them by de-duplicating with a hash table. For
the sake of convenience and efficiency, this class internally stores a
SimpleTypeSerializer so that it can accept unserialized records. The
same is not true of ContinuationRecordBuilder. The user is required to
create their own instance of ContinuationRecordBuilder.
Differential Revision: https://reviews.llvm.org/D40518
llvm-svn: 319198
Since this isn't a real header - it includes static functions and had
external linkage variables (though this change makes them static, since
that's what they should be) so can't be included more than once in a
program.
llvm-svn: 319082
GNU's --strip-all doesn't strip as aggressively as it could in general.
Currently llvm-objcopy copies the exact behavoir of GNU's --strip-all.
eu-strip is used as a drop in replacement for GNU strip/objcopy in many many
places without issue. eu-strip removes non-allocated sections and keeps
.gnu.warning* sections. Because --strip-all will likely be the most widely
used stripping option we should make --strip-all as aggressive as it can safely
be. Since we have evidence from eu-strip that this is a safe option we should
allow it. For those that might still have an issue afterwards I've added
--strip-all-gnu as an exact drop in replacement for GNU's --strip-all as well.
llvm-svn: 319071
The refactoring in r318407 transiently includes abi-breaking.h
which defines EnableABIBreakingChecks. This breaks my Debug
build because this fuzzer did not link in Support with the symbol.
Differential Revision: https://reviews.llvm.org/D40190
llvm-svn: 318553
All these headers already depend on CodeGen headers so moving them into
CodeGen fixes the layering (since CodeGen depends on Target, not the
other way around).
llvm-svn: 318490
It turns out this #include isn't used from Host.h anyway,
but by having it it causes circular include dependencies.
This issues only surfaced while I was working on a separate
patch, so I'm submitting this first so that it's independent
of the other, unrelated patch.
llvm-svn: 318489
Removes AllocateRWX, setWritable and setExecutable from sys::Memory and
standardizes on allocateMappedMemory / protectMappedMemory. The
allocateMappedMemory method is updated to request full permissions for memory
blocks so that they can be marked executable later.
llvm-svn: 318464
Summary:
This change introduces a `DynamicSymbols` field to the ELF specific YAML
supported by `yaml2obj` and `obj2yaml`. This grouping of symbols provides a way
to represent ELF dynamic symbols. The `DynamicSymbols` structure is identical to
the existing `Symbols`.
Reviewers: compnerd, jakehehrlich, silvas
Reviewed By: silvas
Subscribers: silvas, jakehehrlich, llvm-commits
Differential Revision: https://reviews.llvm.org/D39582
llvm-svn: 318433
This moves the file handling out of DwarfLinker.cpp.
This fixes what is at least an oddity if not a bug. DwarfLinker.cpp
was using ToolOutputFile, which uses RemoveFileOnSignal. The issue is
that dsymutil.cpp uses that too. It is now clear from the interface
that only dsymutil.cpp is responsible for creating and deleting files.
llvm-svn: 318334
The original -O binary implementation just copied segment data from the
object and dumped it into a file. This doesn't take into account any
operations performed on objects such as section removal. GNU objcopy has
some specific behavior that we'd also like to respect. For instance
using -O binary and -j <some_section> will dump <some_section> to a
file. This change implements GNU objcopy style -O binary to as close of
an approximation as I can determine.
Differential Revision: https://reviews.llvm.org/D39713
llvm-svn: 318324
Summary:
This patch adds another failure mode for `validateCFIProtection(..)`, wherein any register that affects the indirect control flow instruction is clobbered to between the CFI-check and the instruction's execution.
Also includes a modification to make MCInstrDesc::hasDefOfPhysReg public.
Reviewers: vlad.tsyrklevich
Reviewed By: vlad.tsyrklevich
Subscribers: llvm-commits, pcc, kcc
Differential Revision: https://reviews.llvm.org/D39820
llvm-svn: 318238
Allows users to view GraphResult objects in a DOT directed-graph format. This feature can be turned on through the --print-graphs flag.
Also enabled pretty-printing of instructions in output. Together these features make analysis of unprotected CF instructions much easier by providing a visual control flow graph.
Reviewers: pcc
Subscribers: llvm-commits, kcc, vlad.tsyrklevich
Differential Revision: https://reviews.llvm.org/D39819
llvm-svn: 318211
Clang implements the -finstrument-functions flag inherited from GCC, which
inserts calls to __cyg_profile_func_{enter,exit} on function entry and exit.
This is useful for getting a trace of how the functions in a program are
executed. Normally, the calls remain even if a function is inlined into another
function, but it is useful to be able to turn this off for users who are
interested in a lower-level trace, i.e. one that reflects what functions are
called post-inlining. (We use this to generate link order files for Chromium.)
LLVM already has a pass for inserting similar instrumentation calls to
mcount(), which it does after inlining. This patch renames and extends that
pass to handle calls both to mcount and the cygprofile functions, before and/or
after inlining as controlled by function attributes.
Differential Revision: https://reviews.llvm.org/D39287
llvm-svn: 318195
I was being inconsistent with the way I was capitalizing help messages
for command line options. Additionally --remove-section wasn't using
value_desc even though it benefited from it.
Differential Revision: https://reviews.llvm.org/D39978
llvm-svn: 318190
They don't actually change nay behaviour, as llvm-strings currently
checks the whole object without looking at individual sections anyway.
This allows using llvm-strings in a context that explicitly passes
the -a option.
Differential Revision: https://reviews.llvm.org/D40020
llvm-svn: 318185
This change adds a new flag not present in GNU objcopy that we call
--strip-non-alloc.
Differential Revision: https://reviews.llvm.org/D39926
llvm-svn: 318168
We haven't been supporting anything but ELF64LE since the start. Luckily
this was always accounted for and the change is pretty trivial. B35281
requests this change for ELF32LE. This change adds support for ELF32LE,
ELF64BE, and ELF32BE with all supported features that already existed
for ELF64LE.
Differential Revision: https://reviews.llvm.org/D39977
llvm-svn: 318166
Many projects use this option. There are two ways to use it. You can
either a) Just use --strip-debug and keep the old file with debug
content or b) you can use --strip-debug, --only-keep-debug, and
--add-gnu-debuglink all in conjunction to create two separate files, the
stripped file and the debug file. --only-keep-debug is more complicated
than --strip-debug because it keeps the section headers without keeping
section contents. That's not really supported by llvm-objcopy at the
moment but I plan on adding it. So this change just supports a) and
options to support b) will come soon.
Differential Revision: https://reviews.llvm.org/D39919
llvm-svn: 318094
This change adds a slightly less extreme form of stripping. It should
remove any section that starts with ".debug" and should remove any
symbol table or relocations. In general this strips out most of the
stuff you don't need to execute but leaves a number of things around.
This behavior has been designed to be compatible with GNU strip/objcopy
--strip-all so that anywhere you currently use --strip-all you should be
able to use llvm-objcopy as a drop in replacement.
Differential Revision: https://reviews.llvm.org/D39769
llvm-svn: 318092
Also change some default cases into llvm_unreachable in
WindowsResourceCOFFWriter, to make it easier to find if they
are triggerd from within e.g. lld, which supported ARM64 earlier
than llvm-cvtres did.
Differential Revision: https://reviews.llvm.org/D39892
llvm-svn: 317942
Refactors the behaviour of building graphs out of FileAnalysis, allowing for analysis of the GraphResult by the callee without having to rebuild the graph. Means when we want to analyse the constructed graph (planned for later revisions), we don't do repeated work.
Also makes CFI verification in FileAnalysis now return an enum that allows us to differentiate why something failed, not just that it did/didn't fail.
Reviewers: vlad.tsyrklevich
Subscribers: kcc, pcc, llvm-commits
Differential Revision: https://reviews.llvm.org/D39764
llvm-svn: 317927
This change adds generic fuzzing tools capable of running libFuzzer tests on
any optimization pass or combination of them.
Differential Revision: https://reviews.llvm.org/D39555
llvm-svn: 317883
Summary:
This change allows yaml input to control the order of implicitly added sections
(`.symtab`, `.strtab`, `.shstrtab`). The order is controlled by adding a
placeholder section of the given name to the Sections field.
This change is to support changes in D39582, where it is desirable to control
the location of the `.dynsym` section.
This reapplied version fixes:
1. use of a function call within an assert
2. failing lld test which has an unnamed section
3. incorrect section count when given an unnamed section
Additionally, one more test to cover the unnamed section failure.
Reviewers: compnerd, jakehehrlich
Reviewed By: jakehehrlich
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D39749
llvm-svn: 317789
We've worked around bugs in the frontend by ignoring the count from
wrapped segments when a line has at least one region entry segment.
Those frontend bugs are now fixed, so it's time to regenerate the
checked-in covmapping files and remove the workaround.
llvm-svn: 317761
Adds the blacklist behaviour to llvm-cfi-verify. Now will calculate which lines caused expected failures in the blacklist and reports the number of affected indirect CF instructions for each blacklist entry.
Also moved DWARF checking after instruction analysis to improve performance significantly - unrolling the inlining stack is expensive.
Reviewers: vlad.tsyrklevich
Subscribers: aprantl, pcc, kcc, llvm-commits
Differential Revision: https://reviews.llvm.org/D39750
llvm-svn: 317743
Summary:
This change allows yaml input to control the order of implicitly added sections
(`.symtab`, `.strtab`, `.shstrtab`). The order is controlled by adding a
placeholder section of the given name to the Sections field.
This change is to support changes in D39582, where it is desirable to control
the location of the `.dynsym` section.
This reapplied version fixes:
1. use of a function call within an assert
2. failing lld test which has an unnamed section
Additionally, one more test to cover the unnamed section failure.
Reviewers: compnerd, jakehehrlich
Reviewed By: jakehehrlich
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D39749
llvm-svn: 317646
Summary:
This change allows yaml input to control the order of implicitly added sections
(`.symtab`, `.strtab`, `.shstrtab`). The order is controlled by adding a
placeholder section of the given name to the Sections field.
This change is to support changes in D39582, where it is desirable to control
the location of the `.dynsym` section.
Reviewers: compnerd, jakehehrlich
Reviewed By: jakehehrlich
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D39749
llvm-svn: 317622
Minimal tool to convert xray traces to Chrome's Trace Event Format.
Summary:
Make use of Chrome Trace Event format's Duration events and stack frame dict to
produce Json files that chrome://tracing can visualize from xray function call
traces. Trace Event format is more robust and has several features like
argument logging, function categorization, multi process traces, etc. that we
can add as needed. Duration events cover an important base case.
Part of this change is rearranging the code so that the TrieNode data structure
can be used from multiple tools and can carry parameterized baggage on the
nodes. I put the actual behavior changes in llvm-xray convert exclusively.
Exploring the trace of instrumented llc was pretty nifty if overwhelming.
I can envision this being very useful for analyzing contention scenarios or
tuning parameters like batch sizes in a producer consumer queue. For more
targeted traces likemthis, let's talk about how we want to approach trace
pruning.
Reviewers: dberris, pelikan
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D39362
llvm-svn: 317531
This class was split between libIR and libSupport, which breaks under
modular code generation. Move it into the one library that uses it,
ProfileData, to resolve this issue.
llvm-svn: 317366
Adds blacklist parsing behaviour for filtering results into four categories:
- Expected Protected: Things that are not in the blacklist and are protected.
- Unexpected Protected: Things that are in the blacklist and are protected.
- Expected Unprotected: Things that are in the blacklist and are unprotected.
- Unexpected Unprotected: Things that are not in the blacklist and are unprotected.
now can optionally be invoked with a second command line argument, which specifies the blacklist file that the binary was built with.
Current statistics for chromium:
Reviewers: vlad.tsyrklevich
Subscribers: mgorny, llvm-commits, pcc, kcc
Differential Revision: https://reviews.llvm.org/D39525
llvm-svn: 317364
GNU binutils nm doesn't error out on this, and some projects' build
systems can end up doing that in some cases. Allowing that seems like
a better target than trying to avoid user projects passing multiple
-g parameters to $NM.
Differential Revision: https://reviews.llvm.org/D39539
llvm-svn: 317301
The character gets uppercased into 'I' when it's a global symbol.
In GNU binutils, nm prints 'I' for symbols classified by
bfd_is_ind_section - which probably isn't exactly/only import
tables.
When building for win32, (some incarnations of?) libtool has got
rules that try to inspect linked libraries, and in order to
be sure that it is linking to a DLL import library as opposed to
a static library, it expects to find the string " I " in the output
of $NM when run on such an import library.
GNU binutils nm also flags all of the .idata$X chunks as 'i' (while
this patch only makes it set on .idata$2 and .idata$6) and also
flags __imp__function as 'I'.
Differential Revision: https://reviews.llvm.org/D39540
llvm-svn: 317300
Just aligning segment offsets to segment alignment is incorrect and also
wastes more space than is needed. The requirement is that p_offset ==
p_addr modulo p_align *not* that p_offset == 0 modulo p_align. Generally
speaking we've been using p_addr == 0 modulo p_align. In fact yaml2obj
can't even produce a valid situation which causes llvm-objcopy to
produce incorrect results because alignment and offset were both
inherited from the sections the program header covers. This change fixes
this bad behavior in llvm-objcopy.
Differential Revision: https://reviews.llvm.org/D39132
llvm-svn: 317284
The LLVM tools can be used as a replacement for binutils, in which case
it's convenient to create symlinks with the binutils names. Add support
for these symlinks in the build system. As with any other llvm tool
symlinks, the user can limit the installed symlinks by only adding the
desired ones to `LLVM_TOOLCHAIN_TOOLS`.
Differential Revision: https://reviews.llvm.org/D39530
llvm-svn: 317272
Sometimes program headers have larger alignments than any of the
sections they contain. Currently yaml2obj can't produce such files. A
bug recently appeared in llvm-objcopy that failed in such a case. I'd
like to be able to add tests to llvm-objcopy for such cases.
This change adds an optional alignment parameter to program headers that
will be used instead of calculating the alignment.
Differential Revision: https://reviews.llvm.org/D39130
llvm-svn: 317139
These include:
* Several functions for creating an LLVMDIBuilder,
* LLVMDIBuilderCreateCompileUnit,
* LLVMDIBuilderCreateFile,
* LLVMDIBuilderCreateDebugLocation.
Patch by Harlan Haskins.
Differential Revision: https://reviews.llvm.org/D32368
llvm-svn: 317135
This makes the command line options consistent with llvm-cov and
llvm-profdata, which both use `-num-threads` and `-j`.
This also addresses the conflict reported after landing D39355.
Differential revision: https://reviews.llvm.org/D39496
llvm-svn: 317104
Summary: Help differentiate code and data by parsing DWARF information. This will reduce false positive rates where data is placed in executable sections and is mistakenly parsed as code, resulting in an inflation in the number of indirect CF instructions (and hence an inflation of the number of unprotected).
Also prints the DWARF line data around the region of each indirect CF instruction.
Reviewers: pcc
Subscribers: probinson, llvm-commits, vlad.tsyrklevich, mgorny, aprantl, kcc
Differential Revision: https://reviews.llvm.org/D38654
llvm-svn: 317050
This patch adds the --threads option to dsymutil to process
architectures in parallel. The feature is already present in the version
distributed with Xcode, but was not yet upstreamed.
This is NFC as far as the linking behavior is concerned. As threads are
used automatically, the current tests cover the change in
implementation.
Differential revision: https://reviews.llvm.org/D39355
llvm-svn: 316999
The Android relocation packing format is a more compact
format for dynamic relocations in executables and DSOs
that is based on delta encoding and SLEBs. An overview
of the format can be found in the Android source code:
https://android.googlesource.com/platform/bionic/+/refs/heads/master/tools/relocation_packer/src/delta_encoder.h
This patch implements relocation packing using that format.
This implementation uses a more intelligent algorithm for compressing
relative relocations than Android's own relocation packer. As a
result it can generally create smaller relocation sections than
that packer. If I link Chromium for Android targeting ARM32 I get a
.rel.dyn of size 174693 bytes, as compared to 371832 bytes with gold
and the Android packer.
Differential Revision: https://reviews.llvm.org/D39152
llvm-svn: 316775
Patch by Robert Widmann.
Expose getters for MetadataType and TokenType publicly in the C API.
Discovered a need for these while trying to wrap the intrinsics API.
Differential Revision: https://reviews.llvm.org/D38809
llvm-svn: 316762
Summary:
This upstreams a patch from the osxcross [1] toolchain.
It appears that llvm-dsymutil crashes at this place during GCC
bootstrap. Adding the check here seems reasonable, since it operates
on arbitrary input DWARF, not necessarily generated by the LLVM
toolchain, and it seems the un-mangled name need not necessarily exist.
Patch by Thomas Pöchtrager
[1] https://github.com/tpoechtrager/osxcross
Reviewed By: aprantl
Differential Revision: https://reviews.llvm.org/D39336
llvm-svn: 316678
Add the option to lookup an address in the debug information and print
out the file, function, block and line table details.
Differential revision: https://reviews.llvm.org/D38409
llvm-svn: 316619
Add a CFI protection check that is implemented by building a graph and inspecting the output to deduce if the indirect CF instruction is CFI protected. Also added the output of this instruction to printIndirectInstructions().
Reviewers: vlad.tsyrklevich
Subscribers: llvm-commits, kcc, pcc, mgorny
Differential Revision: https://reviews.llvm.org/D38428
llvm-svn: 316610
This is in preparation for testing lld's upcoming relocation packing
feature (D39152). I have verified that this implementation correctly
unpacks the relocations from a Chromium DSO built with gold and the
Android relocation packer for ARM32 and ARM64.
Differential Revision: https://reviews.llvm.org/D39272
llvm-svn: 316543
We need to use a stable sort on instantiation and expansion sub-views to
produce consistent output. Fortunately, we've gotten lucky and the tests
have checks for the stable order.
This is needed to unblock D39245. Once that lands, we'll have better
test coverage for sort non-determinism.
llvm-svn: 316490
Probably due to a change of how some pass initializes its dependencies,
the -write-bitcode pass (Bitcode/Writer/BitcodeWriterPass.cpp) is not
initialized in opt anymore and therefore not usable with
opt -write-bitcode
Explicitly call initializeWriteBitcodePassPass() to make it available
in opt again.
Differential Revision: https://reviews.llvm.org/D39223
llvm-svn: 316464
The type index is from the TPI stream, not the IPI stream. Fix the
dumper, fix type index discovery, and add a test in LLD.
Also improve the log message we emit when we fail to rewrite type
indices in LLD. That's how I found this bug.
llvm-svn: 316461
Implement a localised graph builder for indirect control flow
instructions. Main interface is through GraphBuilder::buildFlowGraph,
which will build a flow graph around an indirect CF instruction. Various
modifications to FileVerifier are also made to const-expose some members
needed for machine code analysis done by the graph builder.
Reviewers: vlad.tsyrklevich
Reviewed By: vlad.tsyrklevich
Subscribers: llvm-commits, kcc, pcc
Differential Revision: https://reviews.llvm.org/D38427
llvm-svn: 316372
LineCoverageIterator makes it easy for clients of coverage data to
determine line execution counts for a file or function. The coverage
iteration logic is tricky enough that it really pays not to have
multiple copies of it. Hopefully having just one implementation in LLVM
will make the iteration logic easier to test, reuse, and update.
This commit is NFC but I've added a unit test to go along with it just
because it's easy to do now.
llvm-svn: 316141
llvm-cov tends to highlight too many regions because its policy is to
highlight all region entry segments. This can look confusing to users:
not all region entry segments are interesting and deserve highlighting.
Emitting these highlights only when the region count differs from the
line count is a more user-friendly policy.
llvm-svn: 316109
Instead of copying around the wrapped segment and the list of line
segments, just pass a reference to a LineCoverageStats object. This
simplifies the interface. It also makes an upcoming change to suppress
distracting highlights possible.
llvm-svn: 316108
llvm-cov typically doesn't highlight gap segments, but it should if the
gap occurs after an uncovered region in order to preserve continuity.
llvm-svn: 316107
Summary:
llvm-cfi-verify (D38379) introduced a potential build failure when compiling with `-DLLVM_BUILD_LLVM_DYLIB=ON -DLLVM_LINK_LLVM_DYLIB=ON`. Specific versions of cmake seem to treat the `add_subdirectory()` rule differently. It seems as if old versions of cmake BFS these rules, adding them to the fringe for expansion later. Newer versions of cmake seem to immediately execute CMakeFiles that are present in this subdirectory.
If the subdirectory is expanded through the fringe, the globbing resultant from `llvm_add_implicit_projects()` from `cmake/modules/AddLLVM.cmake:1012` means that `tools/llvm-shlib/CMakeFile.txt` gets executed before `tools/llvm-cfi-verify/lib/CMakeFile.txt`. As the latter CMakeFile adds a new library, this expansion order means that the library files required the unit tests in `unittests/tools/llvm-cfi-verify/` are not present in the dynamic library. This causes unit tests to fail as the required functions can't be found.
This change now ensures that the libraries created by `llvm-cfi-verify` are statically linked into the unit tests. As `tools/llvm-cfi-verify/lib` no longer adds anything to `llvm-shlib`, there should be no concern about the order-of-compilation.
Reviewers: skatkov, pcc
Reviewed By: skatkov, pcc
Subscribers: llvm-commits, kcc, pcc, aheejin, vlad.tsyrklevich, mgorny
Differential Revision: https://reviews.llvm.org/D39020
llvm-svn: 316059
In r315960, I accidentally assumed that the first line segment is
guaranteed to be the non-gap region entry segment (given that one is
present). It can actually be any segment on the line, and the test I
checked in demonstrates that.
llvm-svn: 315963
Gap areas make it possible to correctly determine when to use counts
from deferred regions. Before gap areas were introduced, llvm-cov needed
to use a heuristic to do this: it ignored counts from segments that
start, but do not end, on a line. This heuristic breaks down on a simple
example (see PR34962).
This patch removes the heuristic and picks counts from any region entry
segment which isn't a gap area.
llvm-svn: 315960
There were two copies of the logic needed to construct a line stats
object for each line in a range: this patch brings it down to one. In
the future, this will make it easier for IDE clients to display coverage
in-line in source editors. To do that, we just need to move the new
LineCoverageIterator class to libCoverage.
llvm-svn: 315789
Summary:
Documentation says that user can specify sources for both "show" and
"report" commands. "Show" command respects specified sources, but "report" does
not. It is useful to have both "show" and "report" generated for specified
sources. Also added tests to for both commands with sources specified.
Reviewers: vsk, kcc
Reviewed By: vsk
Differential Revision: https://reviews.llvm.org/D38860
llvm-svn: 315685
This patch adds timestamp verification for swiftmodule files. A new flag
is provided to allows us to disable this check in order to allow testing
of this feature.
Differential revision: https://reviews.llvm.org/D38686
llvm-svn: 315684
Reverting to investigate layering effects of MCJIT not linking
libCodeGen but using TargetMachine::getNameWithPrefix() breaking the
lldb bots.
This reverts commit r315633.
llvm-svn: 315637
Summary:
As the first step to allow analysis and visualization of xray collected data,
allow using the llvm-xray stacks tool to emit a complete listing of stacks in
the format consumable by a flamegraph tool.
Possible follow up formats include chrome trace viewer format and sql load
files.
As a POC, I'm able to generate flamegraphs of an xray instrumented llc compiling
hello world.
Reviewers: dberris, pelikan
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D38650
llvm-svn: 315635
Merge LLVMTargetMachine into TargetMachine.
- There is no in-tree target anymore that just implements TargetMachine
but not LLVMTargetMachine.
- It should still be possible to stub out all the various functions in
case a target does not want to use lib/CodeGen
- This simplifies the code and avoids methods ending up in the wrong
interface.
Differential Revision: https://reviews.llvm.org/D38489
llvm-svn: 315633
Here we add a secondary option parser to llvm-isel-fuzzer (and provide
it for use with other fuzzers). With this, you can copy the fuzzer to
a name like llvm-isel-fuzzer=aarch64-gisel for a fuzzer that fuzzer
AArch64 with GlobalISel enabled, or fuzzer=x86_64 to fuzz x86, with no
flags required. This should be useful for running these in OSS-Fuzz.
Note that this handrolls a subset of cl::opts to recognize, rather
than embedding a complete command parser for argv[0]. If we find we
really need the flexibility of handling arbitrary options at some
point we can rethink this.
This re-applies 315545 using "=" instead of ":" as a separator for
arguments.
llvm-svn: 315557
It broke some tests on Windows:
Failing Tests (4):
LLVM :: tools/llvm-isel-fuzzer/execname-options.ll
LLVM :: tools/llvm-isel-fuzzer/missing-triple.ll
LLVM :: tools/llvm-isel-fuzzer/x86-empty-bc.ll
LLVM :: tools/llvm-isel-fuzzer/x86-empty.ll
> llvm-isel-fuzzer: Handle a subset of backend flags in the executable name
>
> Here we add a secondary option parser to llvm-isel-fuzzer (and provide
> it for use with other fuzzers). With this, you can copy the fuzzer to
> a name like llvm-isel-fuzzer:aarch64-gisel for a fuzzer that fuzzer
> AArch64 with GlobalISel enabled, or fuzzer:x86_64 to fuzz x86, with no
> flags required. This should be useful for running these in OSS-Fuzz.
>
> Note that this handrolls a subset of cl::opts to recognize, rather
> than embedding a complete command parser for argv[0]. If we find we
> really need the flexibility of handling arbitrary options at some
> point we can rethink this.
llvm-svn: 315554
Here we add a secondary option parser to llvm-isel-fuzzer (and provide
it for use with other fuzzers). With this, you can copy the fuzzer to
a name like llvm-isel-fuzzer:aarch64-gisel for a fuzzer that fuzzer
AArch64 with GlobalISel enabled, or fuzzer:x86_64 to fuzz x86, with no
flags required. This should be useful for running these in OSS-Fuzz.
Note that this handrolls a subset of cl::opts to recognize, rather
than embedding a complete command parser for argv[0]. If we find we
really need the flexibility of handling arbitrary options at some
point we can rethink this.
llvm-svn: 315545
This reverts commit 4e4ee1c507e2707bb3c208e1e1b6551c3015cbf5.
This is failing due to some code that isn't built on MSVC
so I didn't catch. Not immediately obvious how to fix this
at first glance, so I'm reverting for now.
llvm-svn: 315536
MCObjectStreamer owns its MCCodeEmitter -- this fixes the types to reflect that,
and allows us to remove the last instance of MCObjectStreamer's weird "holding
ownership via someone else's reference" trick.
llvm-svn: 315531
There's a lot of misuse of Twine scattered around LLVM. This
ranges in severity from benign (returning a Twine from a function
by value that is just a string literal) to pretty sketchy (storing
a Twine by value in a class). While there are some uses for
copying Twines, most of the very compelling ones are confined
to the Twine class implementation itself, and other uses are
either dubious or easily worked around.
This patch makes Twine's copy constructor private, and fixes up
all callsites.
Differential Revision: https://reviews.llvm.org/D38767
llvm-svn: 315530
Summary: Move llvm-cfi-verify into a class in preparation for CFI analysis to come.
Reviewers: vlad.tsyrklevich
Reviewed By: vlad.tsyrklevich
Subscribers: mgorny, llvm-commits, pcc, kcc
Differential Revision: https://reviews.llvm.org/D38379
llvm-svn: 315504
Previously we would only look in the current directory for a
resource, which might not be the same as the directory of the
rc file. Furthermore, MSVC rc supports a /I option, and can
also look in the system environment. This patch adds support
for this search algorithm.
Differential Revision: https://reviews.llvm.org/D38740
llvm-svn: 315499
ubsan caught an issue I made where I was converting a null pointer to a
reference.
elf utils implements a particularly extreme form of stripping that I'd
like to support. eu-strip has an option called "strip-sections" that
removes all section headers and leaves only program headers and the
segment data. I have implemented this option partly as a test but mainly
because in Fuchsia we would like to use this option to minimize the size
of our executables. The other strip options that are on my list include
--strip-all and --strip-debug. This is a preliminary implementation that
I'd like to start using in Fuchsia builds if possible. This change
implements such a stripping option for llvm-objcopy
Differential Revision: https://reviews.llvm.org/D38335
llvm-svn: 315484
This patch adds timestamp verification for swiftmodule files.
- A new flag is provided to allows us to continue testing of the code
for embedding the__swift_ast. (git doesn't maintain timestamps)
- Adds a new test for fat (arm) binaries.
Differential revision: https://reviews.llvm.org/D38686
llvm-svn: 315456
elf utils implements a particularly extreme form of stripping that I'd
like to support. eu-strip has an option called "strip-sections" that
removes all section headers and leaves only program headers and the
segment data. I have implemented this option partly as a test but mainly
because in Fuchsia we would like to use this option to minimize the size
of our executables. The other strip options that are on my list include
--strip-all and --strip-debug. This is a preliminary implementation that
I'd like to start using in Fuchsia builds if possible. This change
implements such a stripping option for llvm-objcopy
Differential Revision: https://reviews.llvm.org/D38335
llvm-svn: 315412
MCObjectStreamer owns its MCAsmBackend -- this fixes the types to reflect that,
and allows us to remove another instance of MCObjectStreamer's weird "holding
ownership via someone else's reference" trick.
llvm-svn: 315410
This change adds the ability to use the "-R"/"-remove-section" option
multiple times.
Differential Revision: https://reviews.llvm.org/D38332
llvm-svn: 315385
If a Section had Type SHT_STRTAB (which could happen if you had a
.dynstr section) it was possible to cast Section to StringTableSection
and get away with any operation that was supported by SectionBase
without it being noticed. This change makes this bug easier to notice
and fixes it where it occurred. It also made me realize that there was
some duplication of efforts in the loop that calls ::initialize. These
issues are all fixed by this change.
Differential Revision: https://reviews.llvm.org/D38329
llvm-svn: 315372
This reverts commit r315363. It has a simple build failure, but more
importantly I want to confirm that unit tests run in check-all to make
sure that they don't silently break in the future.
llvm-svn: 315370
Summary: Move llvm-cfi-verify into a class in preparation for CFI analysis to come.
Reviewers: vlad.tsyrklevich
Reviewed By: vlad.tsyrklevich
Subscribers: mgorny, llvm-commits, pcc, kcc
Differential Revision: https://reviews.llvm.org/D38379
llvm-svn: 315363
Summary:
D36624 added some python3 compatibility. But that fix has a problem..
With python2 (which is specified by `#!/usr/bin/env python2.7`), if the env variables do not specify the UTF8,
and the source file is UTF8 (contains non-ASCII symbols), then the `.decode('utf-8')` causes the following exception:
```
Reading YAML files...
Rendering HTML files...
8 of 41Traceback (most recent call last):
File "/build/llvm/tools/opt-viewer/opt-viewer.py", line 277, in <module>
print_progress)
File "/build/llvm/tools/opt-viewer/opt-viewer.py", line 213, in generate_report
should_print_progress)
File "/build/llvm/tools/opt-viewer/optpmap.py", line 45, in pmap
result = map(_wrapped_func, func_and_args, *args, **kwargs)
File "/build/llvm/tools/opt-viewer/optpmap.py", line 25, in _wrapped_func
return func(argument)
File "/build/llvm/tools/opt-viewer/opt-viewer.py", line 174, in _render_file
SourceFileRenderer(source_dir, output_dir, filename).render(remarks)
File "/build/llvm/tools/opt-viewer/opt-viewer.py", line 125, in render
self.render_source_lines(self.source_stream, line_remarks)
File "/build/llvm/tools/opt-viewer/opt-viewer.py", line 79, in render_source_lines
</tr>'''.format(**locals()), file=self.stream)
UnicodeEncodeError: 'ascii' codec can't encode character u'\xf4' in position 47: ordinal not in range(128)
```
This is similar to https://bugs.llvm.org/show_bug.cgi?id=33548, which was fixed by https://reviews.llvm.org/D37661
Unlike that fix, here, *removing* `.decode('utf-8')` actually fixes it.
Since i assume that the original fix is needed, i simply made
that fix conditional, since for python2 it actually breaks things.
Reviewers: modocache, anemet
Reviewed By: anemet
Subscribers: fhahn, llvm-commits
Differential Revision: https://reviews.llvm.org/D38289
llvm-svn: 315350
This change adds support for removing sections using the -R field (as
GNU objcopy does as well). This change should let us add many helpful
tests and is a proper stepping stone for adding more general kinds of
stripping.
Differential Revision: https://reviews.llvm.org/D38260
llvm-svn: 315346
Some functions were taking Twine's not by const&, these are all
fixed to take by const&. We also had a case where some functions
were overloaded to accept by const& and &&. Now there is only
one version which accepts by value and move's the value.
llvm-svn: 315229
Summary:
swiftc emits symbols without flags set, which led dsymutil to ignore
them when searching for global symbols, causing dwarf location data
to be omitted. Xcode's dsymutil handles this case correctly, and emits
valid location data. Add this functionality to llvm-dsymutil by
allowing parsing of symbols with no flags set.
Reviewers: aprantl, friss, JDevlieghere
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D38587
llvm-svn: 315218
This allows rc files to have comments. Eventually we should
just use clang's c preprocessor, but that's a bit larger
effort for minimal gain, and this is straightforward.
Differential Revision: https://reviews.llvm.org/D38651
llvm-svn: 315207
This allows the escape sequences (\a, \n, \r, \t, \\, \x[0-9a-f]*,
\[0-7]*, "") to appear in .rc scripts. These are parsed and output in
the same way as it's done in original MS implementation.
The way these sequences are processed depends on the type of the
resource it resides in, and on whether the user declared the string to
be "wide" or "narrow".
I tried to maintain the maximum compatibility with the original tool
(and fail in some erroneous situations that are accepted by .rc).
However, there are some (extremely rare) cases where Microsoft tool
outputs nonsense. I found it infeasible to detect such casses.
Patch by Marek Sokolowski
Differential Revision: https://reviews.llvm.org/D38426
llvm-svn: 315118
This allows rc to serialize user-defined resources, as
documented at:
msdn.microsoft.com/en-us/library/windows/desktop/aa381054.aspx
Escape sequences are yet unavailable, and are to be added in one of
child patches.
Patch by: Marek Sokolowski
Differential Revision: https://reviews.llvm.org/D38423
llvm-svn: 315117
This allows llvm-rc to serialize STRINGTABLE resources.
These are output in an unusual way: we locate them at the end of the
file, and strings are merged into bundles of max 16 strings, depending
on their IDs, language, and characteristics.
Ref: msdn.microsoft.com/en-us/library/windows/desktop/aa381050.aspx
Patch by: Marek Sokolowski
Differential Revision: https://reviews.llvm.org/D38420
llvm-svn: 315112
This is now able to dump VERSIONINFO resources.
Ref: msdn.microsoft.com/en-us/library/windows/desktop/aa381058.aspx
Differential Revision: https://reviews.llvm.org/D38410
Patch by: Marek Sokolowski
llvm-svn: 315110
This is part 6 of llvm-rc serialization.
This adds ability to output cursors and icons as resources.
Unfortunately, we can't just copy .cur or .ico files to output - as each
file might contain multiple images, each of them needs to be unpacked
and stored as a separate resource. This forces us to parse cursor and
icon contents. (Fortunately, these formats are pretty similar and can be
processed by mostly common code).
As test files are binary, here is a short explanation of .cur and .ico
files stored:
cursor.cur, cursor-8.cur, cursor-32.cur are sample correct cursor files,
differing in their bit depth.
icon-old.ico, icon-new.ico are sample correct icon files;
icon-png.ico is a sample correct icon file in PNG format (instead of
usual BMP);
cursor-eof.cur is an incorrect cursor file - this is cursor.cur with
some of its final bytes removed.
cursor-bad-offset.cur is an incorrect cursor file - image header states
that image data begins at offset 0xFFFFFFFF.
Sample correct cursors and icons were created by Nico Weber.
Patch by Marek Sokolowski
Differential Revision: https://reviews.llvm.org/D37878
llvm-svn: 315109
This is part 5 of llvm-rc serialization support.
This allows DIALOG and DIALOGEX to serialize if dialog-specific optional
statements are provided. These are (as of now): CAPTION, FONT, and
STYLE.
Notably, FONT statement can take more than two arguments when describing
DIALOGEX resources (as in
msdn.microsoft.com/en-us/library/windows/desktop/aa381013.aspx). I made
some changes to the parser to reflect this fact.
Patch by Marek Sokolowski
Differential Revision: https://reviews.llvm.org/D37864
llvm-svn: 315104
At the last LLVM dev meeting we had a debug info for optimized code
BoF session. In that session I presented some graphs that showed how
the quality of the debug info produced by LLVM changed over the last
couple of years. This is a cleaned up version of the patch I used to
collect the this data. It is implemented as an extension of
llvm-dwarfdump, adding a new --statistics option. The intended
use-case is to automatically run this on the debug info produced by,
e.g., our bots, to identify eyebrow-raising changes or regressions
introduced by new transformations that we could act on.
In the current form, two kinds of data are being collected:
- The number of variables that have a debug location versus the number
of variables in total (this takes into account inlined instances of
the same function, so if a variable is completely missing form only
one instance it will be found).
- The PC range covered by variable location descriptions versus the PC
range of all variables' containing lexical scopes.
The output format is versioned and extensible, so I'm looking forward
to both bug fixes and ideas for other data that would be interesting
to track.
Differential Revision: https://reviews.llvm.org/D36627
llvm-svn: 315101
Summary:
swiftc emits symbols without flags set, which led dsymutil to ignore
them when searching for global symbols, causing dwarf location data
to be omitted. Xcode's dsymutil handles this case correctly, and emits
valid location data. Add this functionality to llvm-dsymutil by
allowing parsing of symbols with no flags set.
Reviewers: aprantl, friss, JDevlieghere
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D38587
llvm-svn: 315082
Summary:
xar_open and xar_iter_new require manual calls to close/free functions
to deallocate resources. This makes it easy to introduce memory leaks,
so add RAII struct wrappers for these resources.
Reviewers: enderby, rafael, compnerd, lhames, dblaikie
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D38598
llvm-svn: 315069
Summary:
Xcode's dsymutil emits a __swift_ast DWARF section, which is required for debugging,
and which contains a byte-for-byte dump of the swiftmodule file.
Add this feature to llvm-dsymutil.
Tested with `gobjdump --dwarf=info -s`, by verifying that the contents of
`__DWARF.__swift_ast` match between Xcode's dsymutil and llvm-dsymutil
(Xcode's dwarfdump and llvm-dwarfdump don't currently recognize the
__swift_ast section).
Reviewers: aprantl, friss
Subscribers: llvm-commits, JDevlieghere
Differential Revision: https://reviews.llvm.org/D38504
llvm-svn: 315066
Summary:
Xcode's dsymutil emits a __swift_ast DWARF section, which is required for debugging,
and which contains a byte-for-byte dump of the swiftmodule file.
Add this feature to llvm-dsymutil.
Tested with `gobjdump --dwarf=info -s`, by verifying that the contents of
`__DWARF.__swift_ast` match between Xcode's dsymutil and llvm-dsymutil
(Xcode's dwarfdump and llvm-dwarfdump don't currently recognize the
__swift_ast section).
Reviewers: aprantl, friss
Subscribers: llvm-commits, JDevlieghere
Differential Revision: https://reviews.llvm.org/D38504
llvm-svn: 315014
Summary:
Xcode's dsymutil emits a __swift_ast DWARF section, which is required for debugging,
and which contains a byte-for-byte dump of the swiftmodule file.
Add this feature to llvm-dsymutil.
Tested with `gobjdump --dwarf=info -s`, by verifying that the contents of
`__DWARF.__swift_ast` match between Xcode's dsymutil and llvm-dsymutil
(Xcode's dwarfdump and llvm-dwarfdump don't currently recognize the
__swift_ast section).
Reviewers: aprantl, friss
Subscribers: llvm-commits, JDevlieghere
Differential Revision: https://reviews.llvm.org/D38504
llvm-svn: 315004
Adds the option 'new-pass-manager' to the gold pluggin to enable using the
new pass manager during the lto/thinlto link step.
Patch by Graham Yiu.
Differential Revision: https://reviews.llvm.org/D38517
llvm-svn: 314963
But now include a check for CPU_COUNT so we still build on 10 year old
versions of glibc.
Original message:
Use sched_getaffinity instead of std:🧵:hardware_concurrency.
The issue with std:🧵:hardware_concurrency is that it forwards
to libc and some implementations (like glibc) don't take thread
affinity into consideration.
With this change a llvm program that can execute in only 2 cores will
use 2 threads, even if the machine has 32 cores.
This makes benchmarking a lot easier, but should also help if someone
doesn't want to use all cores for compilation for example.
llvm-svn: 314931
This is a follow-up to https://reviews.llvm.org/D38138.
I fixed the capitalization of some functions because we're changing those
lines anyway and that helped verify that we weren't accidentally dropping
any options by using default param values.
llvm-svn: 314930
Summary:
This reverts D38481. The change breaks systems with older versions of glibc. It
injects a use of CPU_COUNT() from sched.h without checking to ensure that the
function exists first.
Reviewers:
Subscribers:
llvm-svn: 314922
Somehow a few massive errors slipped though the cracks of testing.
1. The code in Segment::finalize was left over from the old layout
algorithm. In certain situations this would cause very strange issues
with segment layout. For instance in the shift-segments.test case it
would cause the second segment to have the same offset as the first.
2. In debugging this I discovered another issue. Namely section alignment
was not being computed based on Section->Align but instead
Section->Offset which is bizarre and makes no sense. I have no clue how
it worked in the first place. This issue is also fixed
3. Fixing #2 exposed a bug where things were not being written past the end
of the file that technically should have been. This was because in
certain cases (like overlapping-segments) the end of the file wouldn't
always be bumped if the offset could be chosen relative to an existing
segment that already had it's offset chosen. For fully nested segments
this is fine but for overlapping segments this leaves the end of the
file short. So I changed how the offset is bumped when looping though
segments.
Differential Revision: https://reviews.llvm.org/D38436
llvm-svn: 314918
The test fails on Linux; see follow-up email on the llvm-commits list.
> Add the option to lookup an address in the debug information and print
> out the file, function, block and line table details.
>
> Differential revision: https://reviews.llvm.org/D38409
This also reverts the follow-up r314818:
> [test] Fix llvm-dwarfdump/cmdline.test
>
> Fixes test/tools/llvm-dwarfdump/cmdline.test
llvm-svn: 314825
The list of register ids was previously written out in a couple of dirrent
places. This puts it in a .def file and also adds a few more registers (e.g.
the x87 regs) which should lead to more readable dumps, but I didn't include
the whole list since that seems unnecessary.
X86_MC::initLLVMToSEHAndCVRegMapping is pretty ugly, but at least it's not
relying on magic constants anymore. The TODO of using tablegen still stands.
Differential revision: https://reviews.llvm.org/D38480
llvm-svn: 314821
Add the option to lookup an address in the debug information and print
out the file, function, block and line table details.
Differential revision: https://reviews.llvm.org/D38409
llvm-svn: 314817
The issue with std:🧵:hardware_concurrency is that it forwards
to libc and some implementations (like glibc) don't take thread
affinity into consideration.
With this change a llvm program that can execute in only 2 cores will
use 2 threads, even if the machine has 32 cores.
This makes benchmarking a lot easier, but should also help if someone
doesn't want to use all cores for compilation for example.
llvm-svn: 314809
This came out of a recent discussion on llvm-dev
(https://reviews.llvm.org/D38042). Currently the Verifier will strip
the debug info metadata from a module if it finds the dbeug info to be
malformed. This feature is very valuable since it allows us to improve
the Verifier by making it stricter without breaking bcompatibility,
but arguable the Verifier pass should not be modifying the IR. This
patch moves the stripping of broken debug info into AutoUpgrade
(UpgradeDebugInfo to be precise), which is a much better location for
this since the stripping of malformed (i.e., produced by older, buggy
versions of Clang) is a (harsh) form of AutoUpgrade.
This change is mostly NFC in nature, the one big difference is the
behavior when LLVM module passes are introducing malformed debug
info. Prior to this patch, a NoAsserts build would have printed a
warning and stripped the debug info, after this patch the Verifier
will report a fatal error. I believe this behavior is actually more
desirable anyway.
Differential Revision: https://reviews.llvm.org/D38184
llvm-svn: 314699
This is now able to serialize DIALOG and DIALOGEX resources to .res
files. It still can't parse dialog-specific CAPTION, FONT, and STYLE
optional statement - these will be added in the following patch.
A limited set of controls is included. However, more can be easily added
by extending SupportedCtls map defined in ResourceScriptStmt.cpp.
Differential Revision: https://reviews.llvm.org/D37862
llvm-svn: 314578
This allows MENU resources to be serialized.
MENU resource statement doc:
msdn.microsoft.com/en-us/library/windows/desktop/aa381025.aspx
POPUP sub-statement doc:
msdn.microsoft.com/en-us/library/windows/desktop/aa381030.aspx
MENUITEM sub-statement doc:
msdn.microsoft.com/en-us/library/windows/desktop/aa381024.aspx
MENUHEADER structure:
msdn.microsoft.com/en-us/library/windows/desktop/ms648018.aspx (and
NORMALMENUITEM, POPUPMENUITEM structs).
Thanks for Nico Weber for his original work in this area.
Differential Revision: https://reviews.llvm.org/D37828
llvm-svn: 314562
Zachary Turner