| Age | Commit message (Collapse) | Author |
|---|
|
Summary:
Before this change, XRay would conservatively patch sections of the code
one sled at a time. Upon testing/profiling, this turns out to take an
inordinate amount of time and cycles. For an instrumented clang binary,
the cycles spent both in the patching/unpatching routine constituted 4%
of the cycles -- this didn't count the time spent in the kernel while
performing the mprotect calls in quick succession.
With this change, we're coalescing the number of calls to mprotect from
being linear to the number of instrumentation points, to now being a
lower constant when patching all the sleds through `__xray_patch()` or
`__xray_unpatch()`. In the case of calling `__xray_patch_function()` or
`__xray_unpatch_function()` we're now doing an mprotect call once for
all the sleds for that function (reduction of at least 2x calls to
mprotect).
Reviewers: kpw, eizan
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D41153
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@320664 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Summary:
This change implements the basic mode filtering similar to what we do in
FDR mode. The implementation is slightly simpler in basic-mode filtering
because we have less details to remember, but the idea is the same. At a
high level, we do the following to decide when to filter function call
records:
- We maintain a per-thread "shadow stack" which keeps track of the
XRay instrumented functions we've encountered in a thread's
execution.
- We push an entry onto the stack when we enter an XRay instrumented
function, and note the CPU, TSC, and type of entry (whether we have
payload or not when entering).
- When we encounter an exit event, we determine whether the function
being exited is the same function we've entered recently, was
executing in the same CPU, and the delta of the recent TSC and the
recorded TSC at the top of the stack is less than the equivalent
amount of microseconds we're configured to ignore -- then we un-wind
the record offset an appropriate number of times (so we can
overwrite the records later).
We also support limiting the stack depth of the recorded functions,
so that we don't arbitrarily write deep function call stacks.
Reviewers: eizan, pelikan, kpw, dblaikie
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D40828
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@319762 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Summary:
This change allows for registration of multiple logging implementations
through a central mechanism in XRay, mapping an implementation to a
"mode". Modes are strings that are used as keys to determine which
implementation to install through a single API. This mechanism allows
users to choose which implementation to install either from the
environment variable 'XRAY_OPTIONS' with the `xray_mode=` flag, or
programmatically using the `__xray_select_mode(...)` function.
Here, we introduce two API functions for the XRay logging:
__xray_log_register_mode(Mode, Impl): Associates an XRayLogImpl to a
string Mode. We can only have one implementation associated with a given
Mode.
__xray_log_select_mode(Mode): Finds the associated Impl for Mode and
installs it as if by calling `__xray_set_log_impl(...)`.
Along with these changes, we also deprecate the xray_naive_log and
xray_fdr_log flags and encourage users to instead use the xray_mode
flag.
Reviewers: kpw, dblaikie, eizan, pelikan
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D40703
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@319759 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Summary:
Before this patch, XRay's basic (naive mode) logging would be
initialised and installed in an adhoc manner. This patch ports the
implementation of the basic (naive mode) logging implementation to use
the common XRay framework.
We also make the following changes to reduce the variance between the
usage model of basic mode from FDR (flight data recorder) mode:
- Allow programmatic control of the size of the buffers dedicated to
per-thread records. This removes some hard-coded constants and turns
them into runtime-controllable flags and through an Options
structure.
- Default the `xray_naive_log` option to false. For now, the only way
to start basic mode is to set the environment variable, or set the
default at build-time compiler options. Because of this change we've
had to update a couple of tests relying on basic mode being always
on.
- Removed the reliance on a non-trivially destructible per-thread
resource manager. We use a similar trick done in D39526 to use
pthread_key_create() and pthread_setspecific() to ensure that the
per-thread cleanup handling is performed at thread-exit time.
We also radically simplify the code structure for basic mode, to move
most of the implementation in the `__xray` namespace.
Reviewers: pelikan, eizan, kpw
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D40164
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@318734 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Summary:
This change fixes the XRay trampolines aside from the __xray_CustomEvent
trampoline to align the stack to 16-byte boundaries before calling the
handler. Before this change we've not been explicitly aligning the stack
to 16-byte boundaries, which makes it dangerous when calling handlers
that leave the stack in a state that isn't strictly 16-byte aligned
after calling the handlers.
We add a test that makes sure we can handle these cases appropriately
after the changes, and prevents us from regressing the state moving
forward.
Fixes http://llvm.org/PR35294.
Reviewers: pelikan, pcc
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D40004
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@318261 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This reverts r317875.
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@317877 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Summary:
This change implements the changes required in both clang and
compiler-rt to allow building XRay-instrumented binaries in Darwin. For
now we limit this to x86_64. We also start building the XRay runtime
library in compiler-rt for osx.
A caveat to this is that we don't have the tests set up and running
yet, which we'll do in a set of follow-on changes.
This patch uses the monorepo layout for the coordinated change across
multiple projects.
Reviewers: kubamracek
Subscribers: mgorny, cfe-commits, llvm-commits
Differential Revision: https://reviews.llvm.org/D39114
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@317875 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Improves the test behaviour in the face of failure. Without this change
the fdr-single-thread.cc test may leave around artefacts of a previous
failing run since the cleanup doesn't happen if any of the intermediary
steps fail.
Non-functional change.
Subscribers: llvm-commits
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@316548 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This is a very poorly named feature. I think originally it meant to cover linux only, but the use of it in msan
seems to be about any aarch64 platform. Anyway, this change should be NFC on everything except Android.
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@315389 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Summary:
This change removes the dependency on using a std::deque<...> for the
storage of the buffers in the buffer queue. We instead implement a
fixed-size circular buffer that's resilient to exhaustion, and preserves
the semantics of the BufferQueue.
We're moving away from using std::deque<...> for two reasons:
- We want to remove dependencies on the STL for data structures.
- We want the data structure we use to not require re-allocation in
the normal course of operation.
The internal implementation of the buffer queue uses heap-allocated
arrays that are initialized once when the BufferQueue is created, and
re-uses slots in the buffer array as buffers are returned in order.
We also change the lock used in the implementation to a spinlock
instead of a blocking mutex. We reason that since the release operations
now take very little time in the critical section, that a spinlock would
be appropriate.
This change is related to D38073.
This change is a re-submit with the following changes:
- Keeping track of the live buffers with a counter independent of the
pointers keeping track of the extents of the circular buffer.
- Additional documentation of what the data members are meant to
represent.
Reviewers: dblaikie, kpw, pelikan
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D38119
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@314877 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Summary:
When the XRay user calls the API to finish writing the log, the thread
which is calling the API still hasn't finished and therefore won't get
its trace written. Add a test for only the main thread to check this.
Reviewers: dberris
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D38493
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@314875 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This reverts r314766 (rL314766). Unit tests fail in multiple bots.
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@314786 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Summary:
This change removes the dependency on using a std::deque<...> for the
storage of the buffers in the buffer queue. We instead implement a
fixed-size circular buffer that's resilient to exhaustion, and preserves
the semantics of the BufferQueue.
We're moving away from using std::deque<...> for two reasons:
- We want to remove dependencies on the STL for data structures.
- We want the data structure we use to not require re-allocation in
the normal course of operation.
The internal implementation of the buffer queue uses heap-allocated
arrays that are initialized once when the BufferQueue is created, and
re-uses slots in the buffer array as buffers are returned in order.
We also change the lock used in the implementation to a spinlock
instead of a blocking mutex. We reason that since the release operations
now take very little time in the critical section, that a spinlock would
be appropriate.
This change is related to D38073.
Reviewers: dblaikie, kpw, pelikan
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D38119
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@314766 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Summary:
Write out records about logged function call first arguments. D32840
implements the reading of this in llvm-xray.
Reviewers: dberris
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D32844
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@314378 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Summary:
This change starts differentiating tail exits from normal exits. We also
increase the version number of the "naive" log to version 2, which will
be the starting version where these records start appearing. In FDR mode
we treat the tail exits as normal exits, and are thus subject to the
same treatment with regard to record unwriting.
Updating the version number is important to signal older builds of the
llvm-xray tool that do not deal with the tail exit records must fail
early (and that users should only use the llvm-xray tool built after
the support for tail exits to get accurate handling of these records).
Depends on D37964.
Reviewers: kpw, pelikan
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D37965
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@313515 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Thesee tests require the integrated assembler which is still in
development / testing for MIPS64. GAS doesn't understand the
section directives produced by XRay, so marking the relevant
tests as unsupported.
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@312628 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Summary:
Before this change we seemed to not be running the unit tests, and therefore we
set out to run them. In the process of making this happen we found a divergence
between the implementation and the tests.
This includes changes to both the CMake files as well as the implementation and
headers of the XRay runtime. We've also updated documentation on the changed
functions.
Reviewers: kpw, eizan
Subscribers: mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D37290
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@312202 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Summary:
This change introduces versions to the instrumentation map entries we
emit for XRay instrumentaiton points. The status quo for the version is
currently set to 0 (as emitted by the LLVM back-end), and versions will
count up to 255 (unsigned char).
This change is in preparation for supporting the newer version of the
custom event sleds that will be emitted by the LLVM compiler.
While we're here, we take the opportunity to stash more registers and
align the stack properly in the __xray_CustomEvent trampoline.
Reviewers: kpw, pcc, dblaikie
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D36816
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@311524 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Summary:
Here we add a build with -ffunction-sections -fdata-sections and
-Wl,--gc-sections to ensure that we're still able to generate XRay
traces.
This is just adding a test, no functional changes.
Differential Revision: https://reviews.llvm.org/D36863
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@311145 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Follow-up to D35789.
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@309543 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Follow-up on D35789.
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@309540 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
The quiet-start.cc test currently fails for arm (and potentially other
platforms). This change limits it to x86_64-linux.
Follow-up to D35789.
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@309538 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
instrumented.
Summary:
Currently when the XRay runtime is linked into a binary that doesn't
have the instrumentation map, we print a warning unconditionally. This
change attempts to make this behaviour more quiet.
Reviewers: kpw, pelikan
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D35789
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@309534 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Fixes build breakage for some bots after we've started logging both the
process id and the thread id.
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@308701 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Followup to D34669.
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@306506 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Followup to D34669.
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@306505 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Summary:
This change introduces two files that show exaples of the
always/never instrument files that can be provided to clang. We don't
add these as defaults yet in clang, which we can do later on (in a
separate change).
We also add a test that makes sure that these apply in the compiler-rt
project tests, and that changes in clang don't break the expectations in
compiler-rt.
Reviewers: pelikan, kpw
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D34669
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@306502 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
same binary
This test makes sure we can handle both arg0 and arg1 handling in the
same binary, and making sure that the XRay runtime calls the correct
trampoline when handlers for both of these cases are installed.
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@305660 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Summary:
This allows us to do more interesting things with the data available to
C++ methods, to log the `this` pointer.
Depends on D34050.
Reviewers: pelikan
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D34051
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@305545 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This change adds __xray_remove_customevent_handler(...) to be consistent
with other APIs that add/remove handlers.
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@303526 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Reviewers: echristo, dberris
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D33266
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@303302 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
We only have an implementation in x86_64 that works for the
patching/unpatching and runtime support (trampolines).
Follow-up to D30630.
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@302873 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Summary:
This change implements support for the custom event logging sleds and
intrinsics at runtime. For now it only supports handling the sleds in
x86_64, with the implementations for other architectures stubbed out to
do nothing.
NOTE: Work in progress, uploaded for exposition/exploration purposes.
Depends on D27503, D30018, and D33032.
Reviewers: echristo, javed.absar, timshen
Subscribers: mehdi_amini, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D30630
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@302857 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Summary:
This bug is caused by the incorrect handling of return-value registers.
According to OpenPOWER 64-Bit ELF V2 ABI 2.2.5, up to 2 general-purpose
registers are going to be used for return values, and up to 8 floating
point registers or vector registers are going to be used for return
values.
Reviewers: dberris, echristo
Subscribers: nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D33027
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@302691 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Summary:
The test fails on PPC, because the address of a function may vary
depending on whether the "taker" shares the same ToC (roughly, in the
same "module") as the function.
Therefore the addresses of the functions taken in func-id-utils.cc may be
different from the addresses taken in xray runtime.
Change the test to be permissive on address comparison.
Reviewers: dberris, echristo
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D33026
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@302686 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Follow-up on D32846.
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@302392 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
When run this test case causes a segementation fault on powerpc64le.
The xfail should be removed when the problem is fixed.
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@302237 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
utilities tests
Follow-up on D32846 to simplify testing and not rely on FileCheck to
test boundary conditions, and instead do all the testing in code
instead.
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@302212 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Summary:
This change allows us to provide users and implementers of XRay handlers
a means of converting XRay function id's to addresses. This, in
combination with the facilities provided in D32695, allows users to find
out:
- How many function id's there are defined in the current binary.
- Get the address of the function associated with this function id.
- Patch only specific functions according to their requirements.
While we don't directly provide symbolization support in XRay, having
the function's address lets users determine this information easily
either during runtime, or offline with tools like 'addr2line'.
Reviewers: dblaikie, echristo, pelikan
Subscribers: kpw, llvm-commits
Differential Revision: https://reviews.llvm.org/D32846
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@302210 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Summary:
This change allows us to patch/unpatch specific functions using the
function ID. This is useful in cases where implementations might want to
do coverage-style, or more fine-grained control of which functions to
patch or un-patch at runtime.
Depends on D32693.
Reviewers: dblaikie, echristo, kpw
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D32695
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@302112 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Summary:
The thread order test fails sometimes my machine independently of standalone
build.
From testing both standalone and in-tree build, I see I configured it wrong.
The other hypothesis for an issue is that cold starts can interfere with whether
record unwriting happens. Once this happens more than once, we can naively
FileCheck on the wrong test output, which compounds the issue.
While "rm blah.* || true" will print to stderr if the glob can't expand, this is
mostly harmless and makes sure earlier failing tests don't sabotage us.
Example failure:
---
header:
version: 1
type: 1
constant-tsc: true
nonstop-tsc: true
cycle-frequency: 3800000000
records:
- { type: 0, func-id: 1, function: 'f1()', cpu: 9, thread: 21377, kind: function-enter, tsc: 2413745203147228 }
- { type: 0, func-id: 1, function: 'f1()', cpu: 9, thread: 21377, kind: function-exit, tsc: 2413745203304238 }
...
The CMAKE related change fixes the expectation that COMPILER_RT_STANDALONE_BUILD will be explicitly FALSE instead
of empty string when it is not "TRUE".
Reviewers: dberris
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D32259
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@300822 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Summary:
Tests that generate output with compiler-rt and verify it with the llvm_xray
command (built from the llvm tree) are extremely convenient, but compiler-rt
can be built out of tree and llvm_xray is not built for every target.
This change intends to disable tests for out of tree builds, but does nothing
to detect whether llvm_xray can be found elsewhere on the path, is fresh enough,
or is part of a build target for the in tree build.
Tested:
Tested that this didn't break check-xray. Haven't reproduced bots or standalone
builds.
Reviewers: dberris, kcc
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D32150
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@300716 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Summary:
"short" is defined as an xray flag, and buffer rewinding happens for both exits
and tail exits.
I've made the choice to seek backwards finding pairs of FunctionEntry, TailExit
record pairs and erasing them if the FunctionEntry occurred before exit from the
currently exiting function. This is a compromise so that we don't skip logging
tail calls if the function that they call into takes longer our duration.
This works by counting the consecutive function and function entry, tail exit
pairs that proceed the current point in the buffer. The buffer is rewound to
check whether these entry points happened recently enough to be erased.
It is still possible we will omit them if they call into a child function that
is not instrumented which calls a fast grandchild that is instrumented before
doing other processing.
Reviewers: pelikan, dberris
Reviewed By: dberris
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D31345
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@299629 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Until llvm-xray starts running/supporting binaries that are not ELF64 we
only run the FDR tests on x86_64-linux. Previous changes caused the
tests to not actually run on x86_64.
Follow-up on D31454.
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@299050 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Followup on D31454.
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@299049 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Followup on D31454.
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@299048 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Summary:
This change allows us to do an end-to-end test of the FDR mode
implementation that uses the llvm-xray tooling to verify that what we
are both writing and reading the data in a consistent manner.
Reviewers: kpw, pelikan
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D31454
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@299042 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Summary:
This change exercises the end-to-end functionality defined in the FDR
logging implementation. We also prepare for being able to run traces
generated by the FDR logging implementation from being analysed with the
llvm-xray command that comes with the LLVM distribution.
This also unblocks D31385, D31384, and D31345.
Reviewers: kpw, pelikan
Subscribers: llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D31452
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@298977 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Summary:
rL297000 and rL297003 implemented arg1 logging on amd64 and made
other architectures build. We need to blacklist the new test as well.
Reviewers: dberris, timshen
Reviewed By: dberris
Subscribers: sdardis, llvm-commits
Differential Revision: https://reviews.llvm.org/D30635
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@297238 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Temporarily mark the test as unsupported so the powerpc le buildbot
testers can get back to work.
There was a brief discussion of this on the mailing list for r296998.
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@297184 91177308-0d34-0410-b5e6-96231b3b80d8
|
