code duplication in the client, and improve error propagation.

This patch moves the OrcRemoteTarget rpc::Function declarations from
OrcRemoteTargetRPCAPI into their own namespaces under llvm::orc::remote so that
they can be used in new contexts (in particular, a remote-object-file adapter
layer that I will commit shortly).

Code duplication in OrcRemoteTargetClient (especially in loops processing the
code, rw-data and ro-data allocations) is removed by moving the loop bodies
into their own functions.

Error propagation is (slightly) improved by adding an ErrorReporter functor to
the OrcRemoteTargetClient -- Errors that can't be returned (because they occur
in destructors, or behind stable APIs that don't provide error returns) can be
sent to the ErrorReporter instead. Some methods in the Client API are also
changed to make better use of the Expected class: returning Expected<T>s rather
than returning Errors and taking T&s to store the results.

llvm-svn: 312500

This reverts commit 204a65e0702847a1880336372ad7abd1df414b44.

Double ref qualifier failed bots.

llvm-svn: 312428

This change introduces a subcommand to the llvm-xray tool called
"stacks" which allows for analysing XRay traces provided as inputs and
accounting time to stacks instead of just individual functions. This
gives us a more precise view of where in a program the latency is
actually attributed.

The tool uses a trie data structure to keep track of the caller-callee
relationships as we process the XRay traces. In particular, we keep
track of the function call stack as we enter functions. While we're
doing this we're adding nodes in a trie and indicating a "calls"
relatinship between the caller (current top of the stack) and the callee
(the new top of the stack). When we push function ids onto the stack, we
keep track of the timestamp (TSC) for the enter event.

When exiting functions, we are able to account the duration by getting
the difference between the timestamp of the exit event and the
corresponding entry event in the stack. This works even if we somehow
miss the exit events for intermediary functions (i.e. if the exit event
is not cleanly associated with the enter event at the top of the stack).

The output of the tool currently provides just the top N leaf functions
that contribute the most latency, and the top N stacks that have the
most frequency. In the future we can provide more sophisticated query
mechanisms and potentially an export to database feature to make offline
analysis of the stack traces possible with existing tools.

llvm-svn: 312426

FuzzMutate might not be the best place for these, but it makes more
sense than an entirely new library for now. This will make setting up
fuzz targets with consistent CLI handling easier.

llvm-svn: 312425

The binutils utility dwp has an option "-e" 
https://gcc.gnu.org/wiki/DebugFissionDWP
to specify an executable/library to get the list 
of *.dwo files from it. This option is particularly useful when 
someone runs the tool manually outside of a build system.
This diff adds an implementation of "-e" to llvm-dwp.

Test plan: make check-all

Differential revision: https://reviews.llvm.org/D37371

llvm-svn: 312409

llvm-svn: 312395

llvm-svn: 312359

We have llvm-readobj for dumping CodeView from object files, and
llvm-pdbutil has always been more focused on PDB.  However,
llvm-pdbutil has a lot of useful options for summarizing debug
information in aggregate and presenting high level statistical
views.  Furthermore, it's arguably better as a testing tool since
we don't have to write tests to conform to a state-machine like
structure where you match multiple lines in succession, each
depending on a previous match.  llvm-pdbutil dumps much more
concisely, so it's possible to use single-line matches in many
cases where as with readobj tests you have to use multi-line
matches with an implicit state machine.

Because of this, I'm adding object file support to llvm-pdbutil.
In fact, this mirrors the cvdump tool from Microsoft, which also
supports both object files and pdb files.  In the future we could
perhaps rename this tool llvm-cvutil.

In the meantime, this allows us to deep dive into object files
the same way we already can with PDB files.

llvm-svn: 312358

It's non-trivial to use weak symbols in a cross platform way (See
sanitizer_win_defs.h in compiler-rt), and doing it naively like we
have here causes some build failures:

  http://lab.llvm.org:8011/builders/clang-with-thin-lto-windows/builds/1260

Instead of going down the rabbit hole of emulating weak symbols for
this very trivial dummy fuzzer driver, we can just rely on the fact
that we know which hooks any given fuzz target implements and forward
declare a normal symbol.

llvm-svn: 312354

This should fix the undefined reference to WriteBitcodeToFile here:
http://bb.pgr.jp/builders/i686-mingw32-RA-on-linux/builds/31682

(Why does every different bot seem to have a different level of
finickiness about LLVM_LINK_COMPONENTS?)

llvm-svn: 312345

This should fix the undefined reference to parseBitcodeFile here:
http://bb.pgr.jp/builders/llvm-i686-linux-RA/builds/5785

llvm-svn: 312343

Summary: See https://github.com/WebAssembly/tool-conventions/blob/master/Linking.md

Differential Revision: https://reviews.llvm.org/D37385

llvm-svn: 312342

llvm-svn: 312341

This adds a dummy main so we can build and run the llvm-isel-fuzzer
functionality when we aren't building LLVM with coverage. The approach
here should serve as a template to stop in-tree fuzzers from
bitrotting (See llvm.org/pr34314).

Note that I'll probably move most of the logic in DummyISelFuzzer's
`main` to a library so it's easy to reuse it in other fuzz targets,
but I'm planning on doing that in a follow up that also consolidates
argument handling in our LLVMFuzzerInitialize implementations.

llvm-svn: 312338

Summary:
Before https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?h=v4.9.46&id=84638335900f1995495838fe1bd4870c43ec1f67
test worked because memory allocated with mmap was not counted against RLIMIT_DATA.

Reviewers: eugenis

Subscribers: llvm-commits

Differential Revision: https://reviews.llvm.org/D37366

llvm-svn: 312303

[Analysis] Fix some Clang-tidy modernize-use-using and Include What You Use warnings; other minor fixes. Also affected in files (NFC).

llvm-svn: 312289

Differential Revision: https://reviews.llvm.org/D37347

llvm-svn: 312284

llvm-svn: 312278

This adds a new command line option, -udt-stats, which breaks
down the stats of S_UDT records.  These are one of the biggest
contributors to the size of /DEBUG:FASTLINK PDBs, so they need
some additional tools to be able to analyze their usage.  This
option will dig into each S_UDT record and determine what kind
of record it points to, and then break down the statistics by
the target type.  The goal here is to identify how our object
files differ from MSVC object files in S_UDT records, so that
we can output fewer of them and reach size parity.

llvm-svn: 312276

This patch completes the work done by Frederic Riss to addresses
dsymutil incorrectly considering forward declaration as canonical during
uniquing. This resulted in references to the forward declaration even
after the definition was encountered.

In addition to the test provided by Alexander Shaposhnikov in D29609, I
added another test to cover several scenarios that were mentioned in his
conversation with Fred. We now also check that uniquing still occurs
after the definition was encountered.

For more context please refer to D29609

Differential revision: https://reviews.llvm.org/D37127

llvm-svn: 312274

This reverts commit r312264.

llvm-svn: 312271

This patch completes the work done by Frederic Riss to addresses
dsymutil incorrectly considering forward declaration as canonical during
uniquing. This resulted in references to the forward declaration even
after the definition was encountered.

In addition to the test provided by Alexander Shaposhnikov in D29609, I
added another test to cover several scenarios that were mentioned in his
conversation with Fred. We now also check that uniquing still occurs
after the definition was encountered.

For more context please refer to D29609

Differential revision: https://reviews.llvm.org/D37127

llvm-svn: 312264

This patch changes the default behavior in brief mode to only show the
debug_info section. This is undoubtedly the most popular and likely the
one you'd want in brief mode.

Non-brief mode behavior is not affected and still defaults to all.

Differential revision: https://reviews.llvm.org/D37334

llvm-svn: 312252

Summary: Add a -name-whitelist option, which behaves in the same way as -name, but it reads in multiple function names from the given input file(s).

Reviewers: vsk

Reviewed By: vsk

Subscribers: llvm-commits

Differential Revision: https://reviews.llvm.org/D37111

llvm-svn: 312227

Summary:
Before this patch, llvm-xray account will assume that thread stacks will
not be empty. Unfortunately there are cases where an instrumented
function will see a call to `fork()` which will cause the child process
to not see the start of the function, but only see the end of the
function. The tooling cannot assume that threads will always have
perfect stacks, and so we change it to support this reality.

Reviewers: dblaikie

Subscribers: llvm-commits

Differential Revision: https://reviews.llvm.org/D31870

llvm-svn: 312204

This moves the cmake configuration for fuzzers in LLVM to a new macro,
add_llvm_fuzzer. This will make it easier to keep things consistent
while implementing llvm.org/pr34314.

I've also made a couple of minor functional changes here:

- the fuzzers now use add_llvm_executable rather than add_llvm_tool.
  This means they won't create install targets and stuff like that,
  because those made little sense for these fuzzers.
- I've grouped these under "Fuzzers" rather than in with "Tools" for
  people who build with IDEs.

llvm-svn: 312200

All this does is forward declare the interface functions (and make
sure that they're `extern "C"`), but since we're using libFuzzer from
the toolchain it doesn't make sense to include the local copy of the
interface.

llvm-svn: 312195

Some kinds of relocations do not have symbols, like R_X86_64_RELATIVE
for instance. I would like to test this case in D36554 but currently
can't because symbols are required by yaml2obj. The other option is
using the empty symbol but that doesn't seem quite right to me.

This change makes the Symbol field of Relocation optional and in the
case where the user does not specify a symbol name the Symbol index is 0.

Patch by Jake Ehrlich

Differential Revision: https://reviews.llvm.org/D37276

llvm-svn: 312192

writeArchive returned a pair, but the first element of the pair is always
its first argument on failure, so it doesn't make sense to return it from
the function. This patch change the return type so that it does't return it.

Differential Revision: https://reviews.llvm.org/D37313

llvm-svn: 312177

Summary:
Based on Fred's patch here: https://reviews.llvm.org/D6771

I can't seem to commandeer the old review, so I'm creating a new one.

With that change the locations exrpessions are pretty printed inline in the
DIE tree. The output looks like this for debug_loc entries:

    DW_AT_location [DW_FORM_data4]        (0x00000000
       0x0000000000000001 - 0x000000000000000b: DW_OP_consts +3
       0x000000000000000b - 0x0000000000000012: DW_OP_consts +7
       0x0000000000000012 - 0x000000000000001b: DW_OP_reg0 RAX, DW_OP_piece 0x4
       0x000000000000001b - 0x0000000000000024: DW_OP_breg5 RDI+0)

And like this for debug_loc.dwo entries:
    DW_AT_location [DW_FORM_sec_offset]   (0x00000000
      Addr idx 2 (w/ length 190): DW_OP_consts +0, DW_OP_stack_value
      Addr idx 3 (w/ length 23): DW_OP_reg0 RAX, DW_OP_piece 0x4)

Simple locations without ranges are printed inline:

   DW_AT_location [DW_FORM_block1]       (DW_OP_reg4 RSI, DW_OP_piece 0x4, DW_OP_bit_piece 0x20 0x0)

The debug_loc(.dwo) dumping in changed accordingly to factor the code.

Reviewers: dblaikie, aprantl, friss

Subscribers: mgorny, javed.absar, hiraditya, llvm-commits, JDevlieghere

Differential Revision: https://reviews.llvm.org/D37123

llvm-svn: 312042

This fixes a use-after-free bug that was noticed by a sanitizer buildbot
(http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-fast/builds/7502).

Differential Revision: https://reviews.llvm.org/D37271

llvm-svn: 312028

Since these aren't built by default unless building with coverage (and
even then they aren't built for the check target) they've managed to
bit rot a little.

This just fixes the build. See llvm.org/pr34314 for the plan on making
sure these don't bit rot again.

llvm-svn: 312011

This extends the set of resources parsed by llvm-rc by DIALOG and
DIALOGEX.

Additionally, three optional resource statements specific to these two
resources are added: CAPTION, FONT, and STYLE.

Thanks for Nico Weber for his original work in this area.

Differential Revision: https://reviews.llvm.org/D36905

llvm-svn: 312009

This change adds support for SHT_SYMTAB sections.

Patch by Jake Ehrlich

Differential Revision: https://reviews.llvm.org/D34167

llvm-svn: 311974

llvm-svn: 311968

This implements a fuzzer tool for instruction selection, as described
in my [EuroLLVM 2017 talk][1].

The fuzzer must be given both libFuzzer args and llc-like args to
configure the backend. For example, to fuzz AArch64 GlobalISel at -O0,
you could invoke like so:

  llvm-isel-fuzzer <corpus dirs> -ignore_remaining_args=1 \
                   -mtriple arm64-apple-ios -global-isel -O0

If you would like to seed the fuzzer with an initial corpus, simply
provide a directory of valid LLVM bitcode (not textual IR) as one of
the corpus dirs.

[1]: http://llvm.org/devmtg/2017-03//2017/02/20/accepted-sessions.html#2

llvm-svn: 311964

This extends llvm-rc parsing tool by MENU resource
(msdn.microsoft.com/en-us/library/windows/desktop/aa381025(v=vs.85).aspx).
As for now, MENUEX
(msdn.microsoft.com/en-us/library/windows/desktop/aa381023(v=vs.85).aspx)
seems unnecessary.

Thanks for Nico Weber for his original work in this area.

Differential Revision: https://reviews.llvm.org/D36898

llvm-svn: 311956

This improves the current llvm-rc parser by the ability of parsing
ACCELERATORS statement.

Moreover, some small improvements to the original parsing commit
were made.

Thanks for Nico Weber for his original work in this area.

Differential Revision: https://reviews.llvm.org/D36894

llvm-svn: 311946

This extends the current llvm-rc parser by ICON and HTML resources.
Moreover, some tests have been slightly rewritten.

Thanks for Nico Weber for his original work in this area.

Differential Revision: https://reviews.llvm.org/D36891

llvm-svn: 311939

llvm-svn: 311875