summaryrefslogtreecommitdiffstats
path: root/compiler-rt/test/xray/TestCases/Linux
Commit message (Collapse)AuthorAgeFilesLines
* Remove empty filesKamil Rytarowski2018-02-2220-0/+0
| | | | | | Left over after D43382 llvm-svn: 325744
* Xray instrumentation / enabling more testsKamil Rytarowski2018-02-2220-906/+0
| | | | | | | | | | | | | | | | | Summary: The Unix subdirectory mostly allows only on Linux x86_64 but now we can target x86_64 arch in general. Patch by David CARLIER Reviewers: krytarowski, dberris, emaste Reviewed By: krytarowski, dberris, emaste Subscribers: emaste, llvm-commits, #sanitizers Differential Revision: https://reviews.llvm.org/D43382 llvm-svn: 325743
* [XRay][compiler-rt] Coalesce calls to mprotect to reduce patching overheadDean Michael Berris2017-12-141-7/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | 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 llvm-svn: 320664
* [XRay][compiler-rt] Implement XRay Basic Mode FilteringDean Michael Berris2017-12-051-0/+51
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 llvm-svn: 319762
* [XRay][compiler-rt] Implement logging implementation registrationDean Michael Berris2017-12-051-0/+59
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 llvm-svn: 319759
* [XRay][compiler-rt] Migrate basic mode logging to the XRay frameworkDean Michael Berris2017-11-212-4/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 llvm-svn: 318734
* [XRay][compiler-rt][x86_64] Align the stack before and after calling handlersDean Michael Berris2017-11-151-0/+57
| | | | | | | | | | | | | | | | | | | | | | | | 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 llvm-svn: 318261
* Revert "[XRay][darwin] Initial XRay in Darwin Support"Dean Michael Berris2017-11-101-9/+0
| | | | | | This reverts r317875. llvm-svn: 317877
* [XRay][darwin] Initial XRay in Darwin SupportDean Michael Berris2017-11-101-0/+9
| | | | | | | | | | | | | | | | | | | | | | 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 llvm-svn: 317875
* [XRay][compiler-rt][NFC] Clean up xray log files before running testDean Michael Berris2017-10-251-0/+1
| | | | | | | | | | | | 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 llvm-svn: 316548
* [XRay][compiler-rt] Use a hand-written circular buffer in BufferQueueDean Michael Berris2017-10-041-11/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 llvm-svn: 314877
* [XRay] [compiler-rt] make sure single threaded programs get traced tooMartin Pelikan2017-10-041-0/+37
| | | | | | | | | | | | | | | 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 llvm-svn: 314875
* Revert "[XRay][compiler-rt] Use a hand-written circular buffer in BufferQueue"Dean Michael Berris2017-10-031-37/+11
| | | | | | This reverts r314766 (rL314766). Unit tests fail in multiple bots. llvm-svn: 314786
* [XRay][compiler-rt] Use a hand-written circular buffer in BufferQueueDean Michael Berris2017-10-031-11/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 llvm-svn: 314766
* [XRay] [compiler-rt] FDR logging arg1 handlerMartin Pelikan2017-09-282-4/+15
| | | | | | | | | | | | | | 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 llvm-svn: 314378
* [XRay][compiler-rt] Handle tail-call exits in the XRay runtimeDean Michael Berris2017-09-182-9/+9
| | | | | | | | | | | | | | | | | | | | | | | | 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 llvm-svn: 313515
* [compiler-rt][xray][mips] Mark some tests as unsupported.Simon Dardis2017-09-067-0/+14
| | | | | | | | | 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. llvm-svn: 312628
* [XRay][compiler-rt] Support sled versioning for custom event sledsDean Michael Berris2017-08-232-0/+44
| | | | | | | | | | | | | | | | | | | | | | 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 llvm-svn: 311524
* [XRay][compiler-rt][NFC] Expand the PIC test case for XRayDean Michael Berris2017-08-181-1/+2
| | | | | | | | | | | | | 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 llvm-svn: 311145
* [XRay][compiler-rt] Fix test to not be too strict with output order.Dean Michael Berris2017-07-311-1/+1
| | | | | | Follow-up to D35789. llvm-svn: 309543
* [XRay][compiler-rt] Fix typo for REQUIRES.Dean Michael Berris2017-07-311-1/+1
| | | | | | Follow-up on D35789. llvm-svn: 309540
* [XRay][compiler-rt] Require build-in-tree and x86_64-linux.Dean Michael Berris2017-07-311-0/+4
| | | | | | | | | 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. llvm-svn: 309538
* [XRay][compiler-rt] Do not print the warning when the binary is not XRay ↵Dean Michael Berris2017-07-311-0/+22
| | | | | | | | | | | | | | | | | 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 llvm-svn: 309534
* [XRay][compiler-rt] Update test to account for change in logging format.Dean Michael Berris2017-07-211-1/+1
| | | | | | | Fixes build breakage for some bots after we've started logging both the process id and the thread id. llvm-svn: 308701
* [XRay][compiler-rt][NFC] Move test case into correct directory.Dean Michael Berris2017-06-281-0/+23
| | | | | | Followup to D34669. llvm-svn: 306506
* [XRay][compiler-rt][NFC] Add a test for both arg1 and arg0 handling in the ↵Dean Michael Berris2017-06-191-0/+39
| | | | | | | | | | 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. llvm-svn: 305660
* Add test for logging the implicit "this" argument for C++ member functions.Dean Michael Berris2017-06-161-0/+31
| | | | | | | | | | | | | | | | 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 llvm-svn: 305545
* [XRay][compiler-rt] Add __xray_remove_customevent_handler(...)Dean Michael Berris2017-05-221-1/+1
| | | | | | | This change adds __xray_remove_customevent_handler(...) to be consistent with other APIs that add/remove handlers. llvm-svn: 303526
* [XRay] Fix __xray_function_address on PPC reguarding local entry points.Tim Shen2017-05-171-12/+4
| | | | | | | | | | Reviewers: echristo, dberris Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D33266 llvm-svn: 303302
* [XRay][compiler-rt] Only run custom event logging in x86_64-linuxDean Michael Berris2017-05-121-1/+3
| | | | | | | | | We only have an implementation in x86_64 that works for the patching/unpatching and runtime support (trampolines). Follow-up to D30630. llvm-svn: 302873
* [XRay][compiler-rt] Runtime changes to support custom event loggingDean Michael Berris2017-05-121-0/+38
| | | | | | | | | | | | | | | | | | | | 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 llvm-svn: 302857
* [XRay] Fix XRay PPC return value bug.Tim Shen2017-05-101-3/+0
| | | | | | | | | | | | | | | | | | 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 llvm-svn: 302691
* [XRay] Fix the test func-id-utils.cc on PPC.Tim Shen2017-05-101-9/+15
| | | | | | | | | | | | | | | | | | | | 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 llvm-svn: 302686
* [XRay][compiler-rt] XFAIL on ppcDean Michael Berris2017-05-081-0/+2
| | | | | | Follow-up on D32846. llvm-svn: 302392
* [powerpc] Mark coverage-sample.cc as XFAIL on powerpc64leBill Seurer2017-05-051-0/+3
| | | | | | | When run this test case causes a segementation fault on powerpc64le. The xfail should be removed when the problem is fixed. llvm-svn: 302237
* [XRay][compiler-rt] Remove dependency on FileCheck from function id ↵Dean Michael Berris2017-05-051-18/+14
| | | | | | | | | | 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. llvm-svn: 302212
* [XRay][compiler-rt] Add function id utilities for XRayDean Michael Berris2017-05-051-0/+46
| | | | | | | | | | | | | | | | | | | | | | | | 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 llvm-svn: 302210
* [XRay][compiler-rt] Support patching/unpatching specific functionsDean Michael Berris2017-05-041-0/+88
| | | | | | | | | | | | | | | | | | 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 llvm-svn: 302112
* [XRay] [compiler-rt] - Fix standalone and non-deterministic test issueKeith Wyss2017-04-202-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 llvm-svn: 300822
* Skip tests that use 'llvm_xray' for standalone builds.Keith Wyss2017-04-192-0/+3
| | | | | | | | | | | | | | | | | | | | | | | 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 llvm-svn: 300716
* [XRay] [compiler-rt] Unwriting FDR mode buffers when functions are short.Dean Michael Berris2017-04-061-4/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 llvm-svn: 299629
* [XRay][compiler-rt] Spell REQUIRES properly for x86_64-linuxDean Michael Berris2017-03-302-2/+2
| | | | | | | | | | 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. llvm-svn: 299050
* [XRay][compiler-rt] Only run tests using llvm-xray in x86_64 for nowDean Michael Berris2017-03-302-3/+4
| | | | | | Followup on D31454. llvm-svn: 299049
* [XRay][compiler-rt] XFAIL the FDR mode tests on aarch64-42vmaDean Michael Berris2017-03-302-0/+3
| | | | | | Followup on D31454. llvm-svn: 299048
* [XRay][compiler-rt] Use llvm-xray in FDR mode testsDean Michael Berris2017-03-302-3/+57
| | | | | | | | | | | | | | | 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 llvm-svn: 299042
* [XRay][compiler-rt] Add an end-to-end test for FDR LoggingDean Michael Berris2017-03-291-0/+62
| | | | | | | | | | | | | | | | | | 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 llvm-svn: 298977
* [XRay] [compiler-rt] Mark arg1 logging test as failing on !x86_64.Dean Michael Berris2017-03-071-1/+1
| | | | | | | | | | | | | | | | 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 llvm-svn: 297238
* [PowerPC] mark xray test as unsupported on powerpcle in testsuiteBill Seurer2017-03-071-0/+2
| | | | | | | | | 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. llvm-svn: 297184
* [XRay] [compiler-rt] Allow logging the first argument of a function call.Dean Michael Berris2017-03-061-0/+41
| | | | | | | | | | | | | | | | | | | Summary: Functions with the LOG_ARGS_ENTRY sled kind at their beginning will be handled in a way to (optionally) pass their first call argument to your logging handler. For practical and performance reasons, only the first argument is supported, and only up to 64 bits. Reviewers: javed.absar, dberris Reviewed By: dberris Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D29703 llvm-svn: 297000
* [XRay][compiler-rt] Switch default XRay 'patch_premain' to falseDean Michael Berris2017-02-284-4/+4
| | | | | | | | | | | | | | | | | | | | | | Summary: Currently, we assume that applications built with XRay would like to have the instrumentation sleds patched before main starts. This patch changes the default so that we do not patch the instrumentation sleds before main. This default is more helpful for deploying applications in environments where changing the current default is harder (i.e. on remote machines, or work-pool-like systems). This default (not to patch pre-main) makes it easier to selectively run applications with XRay instrumentation enabled, than with the current state. Reviewers: echristo, timshen Subscribers: mehdi_amini, llvm-commits Differential Revision: https://reviews.llvm.org/D30396 llvm-svn: 296445
OpenPOWER on IntegriCloud