Summary:
This lets you visualize clangd's activity on different threads over time,
and understand critical paths of requests and object lifetimes.
The data produced can be visualized in Chrome (at chrome://tracing), or
in a standalone copy of catapult (http://github.com/catapult-project/catapult)
This patch consists of:
- a command line flag "-trace" that causes clangd to emit JSON trace data
- an API (in Trace.h) allowing clangd code to easily add events to the stream
- several initial uses of this API to capture JSON-RPC requests, builds, logs
Example result: https://photos.app.goo.gl/12L9swaz5REGQ1rm1
Caveats:
- JSON serialization is ad-hoc (isn't it everywhere?) so the API is
limited to naming events rather than attaching arbitrary metadata.
I'd like to fix this (I think we could use a JSON-object abstraction).
- The recording is very naive: events are written immediately by
locking a mutex. Contention on the mutex might disturb performance.
- For now it just traces instants or spans on the current thread.
There are other things that make sense to show (cross-thread flows,
non-thread resources such as ASTs). But we have to start somewhere.
Reviewers: ioeric, ilya-biryukov
Subscribers: cfe-commits, mgorny
Differential Revision: https://reviews.llvm.org/D39086
llvm-svn: 317193
The previous definition of _LIBUNWIND_HIGHEST_DWARF_REGISTER seems
to be a copy of the ARM64 value (introduced in SVN r276128); since
the code actually hasn't compiled properly for arm in dwarf mode
before, this hasn't actually been used. Set it to the correct value
based on the UNW_ARM_* enum values.
The iwmmx control variables have to be made mutable, since they are
touched from within getRegister (which previously wasn't const), and
getRegister is used on a const Registers object in DwarfInstructions.hpp.
Differential Revision: https://reviews.llvm.org/D39251
llvm-svn: 317192
`LLVM_DISTRIBUTION_COMPONENTS` assumes that each component has both
`component` and `install-component` targets. Add a dummy no-op target
for `libclang-headers` to placate this check.
Differential Revision: https://reviews.llvm.org/D39524
llvm-svn: 317188
Rather than looking at model numbers just check for the mmx feature flag. While there promote INTEL_PENTIUM_MMX to a CPU type instead of a subtype so that we don't have weird type with only one subtype.
llvm-svn: 317184
SetOututFileHandle to work with IOBase.
I did make one change after checking with Larry --
I renamed SBDebugger::Flush to FlushDebuggerOutputHandles
and added a short docstring to the .i file to make it
a little clearer under which context programs may need
to use this API.
Differential Revision: https://reviews.llvm.org/D39128
<rdar://problem/34870417>
llvm-svn: 317182
SetOututFileHandle to work with IOBase.
I did make one change after checking with Larry --
I renamed SBDebugger::Flush to FlushDebuggerOutputHandles
and added a short docstring to the .i file to make it
a little clearer under which context programs may need
to use this API.
Differential Revision: https://reviews.llvm.org/D38829
llvm-svn: 317180
An installation rule for the executable with the correct component is
already created by `add_clang_tool`, so the rule in this file is
redundant. Correct the installation component for the Python scripts so
that they also get installed by `install-clang-tidy`.
llvm-svn: 317155
`add_clang_tool` includes a call to `add_clang_executable`, but it also
sets up the install rule, and adds an `install-*` target. The latter is
required for using `LLVM_DISTRIBUTION_COMPONENTS`.
Differential Revision: https://reviews.llvm.org/D39522
llvm-svn: 317150
`add_clang_tool` invokes `add_clang_executable` internally, but it also
takes care of setting up the install rule. It also adds an `install-*`
build target, which is required for `LLVM_DISTRIBUTION_COMPONENTS`.
Differential Revision: https://reviews.llvm.org/D39523
llvm-svn: 317149
It's possible for multiple distribution components to have missing
targets, and it's a lot more convenient to get all those errors in one
shot rather than having to fix them individually.
llvm-svn: 317148
for instantiating its definition.
We model the 'inline'ness as being instantiated with the static data member in
order to track whether the declaration has become a definition yet.
llvm-svn: 317147
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
dwarf&dwo versions were doing it, but gmodules and dsym weren't. All
this function does right now is pass OS=Android to make when targeting
android. This enables us to run dotest without manually passing --env
OS=Android.
llvm-svn: 317130
Similar to the existing code to lower to PACKSS, we can use PACKUS if the input vector's leading zero bits extend all the way to the packed/truncated value.
We have to account for pre-SSE41 targets not supporting PACKUSDW
llvm-svn: 317128
This patch is to rewrite FileOutputBuffer as two separate classes;
one for file-backed output buffer and the other for memory-backed
output buffer. I think the new code is easier to follow because two
different implementations are now actually separated as different
classes.
Unlike the previous implementation, the class that does not replace the
final output file using rename(2) does not create a temporary file at
all. Instead, it allocates memory using mmap(2) and use it. I think
this is an improvement because it is now guaranteed that the temporary
memory region doesn't trigger any I/O and there's now zero chance to
leave a temporary file behind. Also, it shouldn't impose new restrictions
because were using mmap IO too.
Differential Revision: https://reviews.llvm.org/D39449
llvm-svn: 317127
Summary:
quick_exit() and at_quick_exit() were introduced in android NDK 21:
https://android.googlesource.com/platform/prebuilts/ndk/+/dev/platform/sysroot/usr/include/stdlib.h#55
This CL conditions `_LIBCPP_HAS_QUICK_EXIT` on `__ANDROID_API__ >= 21`. The only place this macro is used is in some using declarations: `using ::quick_exit`, `using ::at_quick_exit`.
Also, add a missing include to sys/cdefs.h which is what defines `__BIONIC__`.
Reviewers: thakis, danalbert, EricWF
Reviewed By: danalbert
Subscribers: srhines, krytarowski
Differential Revision: https://reviews.llvm.org/D39479
llvm-svn: 317124
This will enable us to prefer VALIGND/Q during shuffle lowering in order to get the extended register encoding space when BWI isn't available. But if we end up not using the extended registers we can switch VPALIGNR for the shorter VEX encoding.
Differential Revision: https://reviews.llvm.org/D39401
llvm-svn: 317122
Sam McCall