summaryrefslogtreecommitdiffstats
path: root/compiler-rt/lib/xray
Commit message (Collapse)AuthorAgeFilesLines
...
* [XRay][compiler-rt] Support sled versioning for custom event sledsDean Michael Berris2017-08-233-22/+41
| | | | | | | | | | | | | | | | | | | | | | 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
* Fix multi-architecture build for lib/xray.George Karpenkov2017-08-211-1/+1
| | | | | | Differential Revision: https://reviews.llvm.org/D36881 llvm-svn: 311379
* [sanitizers CMake] NFC Refactor the logic for compiling and generating testsGeorge Karpenkov2017-08-151-23/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | into a function. Most CMake configuration under compiler-rt/lib/*/tests have almost-the-same-but-not-quite functions of the form add_X_[unit]tests for compiling and running the tests. Much of the logic is duplicated with minor variations across different sub-folders. This can harm productivity for multiple reasons: For newcomers, resulting CMake files are very large, hard to understand, and hide the intention of the code. Changes for enabling certain architectures end up being unnecessarily large, as they get duplicated across multiple folders. Adding new sub-projects requires more effort than it should, as a developer has to again copy-n-paste the configuration, and it's not even clear from which sub-project it should be copy-n-pasted. With this change the logic of compile-and-generate-a-set-of-tests is extracted into a function, which hopefully makes writing and reading CMake much easier. Differential Revision: https://reviews.llvm.org/D36116 llvm-svn: 310971
* [XRay][compiler-rt] Allow for building the XRay runtime without PREINIT ↵Dean Michael Berris2017-08-032-1/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | initialization. Summary: Define a build-time configuration option for the XRay runtime to determine whether the archive will add an entry to the `.preinit_array` section of the binary. We also allow for initializing the XRay data structures with an explicit call to __xray_init(). This allows us to give users the capability to initialize the XRay data structures on demand. This can allow us to start porting XRay to platforms where `.preinit_array` isn't a supported section. It also allows us to limit the effects of XRay in the initialization sequence for applications that are sensitive to this kind of interference (i.e. large binaries) or those that want to package XRay control in libraries. Future changes should allow us to build two different library archives for the XRay runtime, and allow clang users to determine which version to link. Reviewers: dblaikie, kpw, pelikan Subscribers: mgorny, llvm-commits Differential Revision: https://reviews.llvm.org/D36080 llvm-svn: 309909
* [XRay][compiler-rt] Remove use of std::mutex and std::shared_ptr from global ↵Dean Michael Berris2017-08-023-29/+36
| | | | | | | | | | | | | | | | | | | | | | | | | | scope. Summary: This change attempts to remove all the dependencies we have on std::mutex and any std::shared_ptr construction in global variables. We instead use raw pointers to these objects, and construct them on the heap. In cases where it's possible, we lazily initialize these pointers. While we do not have a replacement for std::shared_ptr yet in compiler-rt, we use this work-around to avoid having to statically initialize the objects as globals. Subsequent changes should allow us to completely remove our dependency on std::shared_ptr and instead have our own implementation of the std::shared_ptr and std::weak_ptr semantics (or completely rewrite the implementaton to not need these standard-library provided abstractions). Reviewers: dblaikie, kpw, pelikan Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D36078 llvm-svn: 309792
* [XRay][compiler-rt] Do not print the warning when the binary is not XRay ↵Dean Michael Berris2017-07-311-1/+2
| | | | | | | | | | | | | | | | | 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
* [sanitizer tests CMake] Factor out CMake logic for compiling sanitizer testsGeorge Karpenkov2017-07-281-14/+3
| | | | | | | | | | | Currently there's a large amount of CMake logic duplication for compiling sanitizer tests. If we add more sanitizers, the duplication will get even worse. This change factors out common compilation commands into a macro available to all sanitizers. llvm-svn: 309405
* [XRay][compiler-rt][NFC] Add example always/never instrument files.Dean Michael Berris2017-06-282-0/+12
| | | | | | | | | | | | | | | | | | | | 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 llvm-svn: 306502
* [XRay][compiler-rt][NFC] Add a name for argument to __xray_set_handler_arg1(...)Dean Michael Berris2017-06-191-2/+2
| | | | | | | Just makes the interface consistent with the other functions in include/xray/xray_interface.h. llvm-svn: 305658
* [XRay][compiler-rt] Add __xray_remove_customevent_handler(...)Dean Michael Berris2017-05-221-0/+5
| | | | | | | 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-1/+8
| | | | | | | | | | Reviewers: echristo, dberris Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D33266 llvm-svn: 303302
* [XRay][compiler-rt] Remove unused variable after refactoringDean Michael Berris2017-05-121-10/+10
| | | | | | Follow-up to D30630. llvm-svn: 302861
* [XRay][compiler-rt] Fix misspeling of XRaySledEntryDean Michael Berris2017-05-122-2/+2
| | | | | | Follow-up to D30630. llvm-svn: 302860
* [XRay][compiler-rt] Runtime changes to support custom event loggingDean Michael Berris2017-05-1212-140/+387
| | | | | | | | | | | | | | | | | | | | 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-13/+77
| | | | | | | | | | | | | | | | | | 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][compiler-rt] Add function id utilities for XRayDean Michael Berris2017-05-051-1/+13
| | | | | | | | | | | | | | | | | | | | | | | | 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-043-33/+107
| | | | | | | | | | | | | | | | | | 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] Document and update the XRay Logging APIDean Michael Berris2017-05-011-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: In this patch we document the requirements for implementations that want to install handlers for the dynamically-controlled XRay "framework". This clarifies what the expectations are for implementations that want to install their handlers using this API (similar to how the FDR logging implementation does so). It also gives users some guarantees on semantics for the APIs. If all goes well, users can decide to use the XRay APIs to control the tracing/logging at the application level, without having to depend on implementation details of the installed logging implementation. This lets users choose the implementation that comes with compiler-rt, or potentially multiple other implementations that use the same APIs. We also add one convenience function (__xray_remove_log_impl()) for explicitly removing the currently installed log implementation. Reviewers: kpw, pelikan Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D32579 llvm-svn: 301784
* [XRay][compiler-rt] Cleanup CFI/CFA annotations on trampolinesDean Michael Berris2017-04-201-19/+14
| | | | | | | | | | | | | | | | | | | | | | Summary: This is a follow-up to D32202. While the previous change (D32202) did fix the stack alignment issue, we were still at a weird state in terms of the CFI/CFA directives (as the offsets were wrong). This change cleans up the SAVE/RESTORE macros for the trampoline, accounting the stack pointer adjustments with less instructions and with some clearer math. We note that the offsets will be different on the exit trampolines, because we don't typically 'call' into this trampoline and we only ever jump into them (i.e. treated as a tail call that's patched in at runtime). Reviewers: eugenis, kpw, pelikan Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D32214 llvm-svn: 300815
* [XRay][compiler-rt] Fix up CFI annotations and stack alignmentDean Michael Berris2017-04-191-43/+46
| | | | | | | | | | | | | | | | | | | Summary: Previously, we had been very undisciplined about CFI annotations with the XRay trampolines. This leads to runtime crashes due to mis-alined stack pointers that some function implementations may run into (i.e. those using instructions that require properly aligned addresses coming from the stack). This patch attempts to clean that up, as well as more accurately use the correct amounts of space on the stack for stashing and un-stashing registers. Reviewers: eugenis, kcc Subscribers: kpw, llvm-commits Differential Revision: https://reviews.llvm.org/D32202 llvm-svn: 300660
* [XRay][compiler-rt] Use emulated TSC when CPU supports rdtscp, but cannot ↵Douglas Yung2017-04-183-6/+23
| | | | | | | | | | | | | | | | | | | | | determine the CPU frequency A problem arises if a machine supports the rdtscp instruction, but the processor frequency cannot be determined by the function getTSCFrequency(). In this case, we want to use the emulated TSC instead. This patch implements that by adding a call to getTSCFrequency() from probeRequiredCPUFeatures(), and the function only returns true if both the processor supports rdtscp and the CPU frequency can be determined. This should fix PR32620. Reviewers: dberris Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D32067 llvm-svn: 300525
* Fix compile errorIsmail Donmez2017-04-121-0/+1
| | | | llvm-svn: 300041
* [XRay] [compiler-rt] Refactor rewinding FDR logging.Martin Pelikan2017-04-121-80/+79
| | | | | | | | | | | | | | | Summary: While there, make the threshold in ticks for the rewind computed only once and not per function, unify the two versions we had and slightly reformat bits according to coding standards. Reviewers: dberris Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D31971 llvm-svn: 300028
* [XRay] [compiler-rt] Simplify FDR logging handler. [NFC]Martin Pelikan2017-04-121-29/+21
| | | | | | | | | | | | | | | | | | Summary: Not repeating screamy failure paths makes the 300+ line function a bit shorter. There's no need to overload the variable name "Buffer" if it only works on the thread local buffer. Fix some comments while there. I plan to move the rewinding logic into a separate function too, but in this diff it would be too much of a mess to comprehend. This is trivially NFC. Reviewers: kpw, dberris Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D31930 llvm-svn: 300018
* [XRay][compiler-rt] Add another work-around to XRay FDR tests when TSC ↵Douglas Yung2017-04-122-2/+5
| | | | | | | | | | | | | | | | | emulation is needed This patch applies a work-around to the XRay FDR tests when TSC emulation is needed because the processor frequency cannot be determined. This fixes PR32620 using the suggestion given by Dean in comment 1. Reviewers: dberris Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D31967 llvm-svn: 300017
* [XRay][compiler-rt] Add support for TSC emulation for x86_64 to ↵Douglas Yung2017-04-111-1/+15
| | | | | | | | | | | | | | | | xray_fdr_logging.cc Previously in r297800, a work-around was created to use TSC emulation on x86_64 when RDTSCP was not available on the host. A similar change was needed in the file xray_fdr_logging.cc which this patch ports over to that file. Eventually the code should be refactored as there will be 3 locations with the same code, but that can be done as a separate step. This patch is just to keep the test from failing on my machine due to an illegal instruction since RDTSCP is not available on my x86_64 linux VM. Reviewers: dberris Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D31909 llvm-svn: 299922
* [XRay][compiler-rt] Remove the xray_fdr_log_printer_toolDean Michael Berris2017-04-112-332/+0
| | | | | | | | | | | | | | | | | | | | Summary: We can move this functionality into LLVM's tools instead, as it no longer is strictly required for the compiler-rt testing infrastructure. It also is blocking the successful bootstrapping of the clang compiler due to a missing virtual destructor in one of the flag parsing library. Since this binary isn't critical for the XRay runtime testing effort anymore (yet), we remove it in the meantime with the hope of moving the functionality in LLVM proper instead. Reviewers: kpw, pelikan, rnk, seurer, eugenis Subscribers: llvm-commits, mgorny Differential Revision: https://reviews.llvm.org/D31926 llvm-svn: 299916
* [XRay][compiler-rt] Remove unused local variableDean Michael Berris2017-04-061-2/+1
| | | | | | | | The local was only referenced in assertions. Follow-up to D31345. llvm-svn: 299644
* [XRay] [compiler-rt] Unwriting FDR mode buffers when functions are short.Dean Michael Berris2017-04-062-3/+139
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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] Write buffer length to FDR log before writing buffer.Dean Michael Berris2017-03-293-6/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Currently the FDR log writer, upon flushing, dumps a sequence of buffers from its freelist to disk. A reader can read the first buffer up to an EOB record, but then it is unclear how far ahead to scan to find the next threads traces. There are a few ways to handle this problem. 1. The reader has externalized knowledge of the buffer size. 2. The size of buffers is in the file header or otherwise encoded in the log. 3. Only write out the portion of the buffer with records. When released, the buffers are marked with a size. 4. The reader looks for memory that matches a pattern and synchronizes on it. 2 and 3 seem the most flexible and 2 does not rule 3 out. This is an implementation of 2. In addition, the function handler for fdr more aggressively checks for finalization and makes an attempt to release its buffer. Reviewers: pelikan, dberris Reviewed By: dberris Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D31384 llvm-svn: 298982
* [XRay][compiler-rt] Add an end-to-end test for FDR LoggingDean Michael Berris2017-03-294-24/+13
| | | | | | | | | | | | | | | | | | 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
* Fix build error:Ismail Donmez2017-03-271-0/+1
| | | | | | | | | | In file included from /home/abuild/rpmbuild/BUILD/llvm/projects/compiler-rt/lib/xray/tests/unit/xray_fdr_log_printer_tool.cc:15: ../projects/compiler-rt/lib/xray/tests/../xray_fdr_logging_impl.h:221:21: error: use of undeclared identifier 'CLOCK_MONOTONIC' wall_clock_reader(CLOCK_MONOTONIC, &TS); ^ 1 error generated. llvm-svn: 298837
* [XRay][compiler-rt] Use sanitizer_common's atomic opsDean Michael Berris2017-03-278-105/+127
| | | | | | | | | | | Instead of std::atomic APIs for atomic operations, we instead use APIs include with sanitizer_common. This allows us to, at runtime, not have to depend on potentially dynamically provided implementations of these atomic operations. Fixes http://llvm.org/PR32274. llvm-svn: 298833
* [XRay] [compiler-rt] Plug a file descriptor leak in a failure case.Martin Pelikan2017-03-241-1/+1
| | | | | | | | | | | | Summary: Fd needs to be closed before the number gets out of scope. Reviewers: dberris Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D31278 llvm-svn: 298685
* [XRay][compiler-rt] Remove dependency on <system_error>Dean Michael Berris2017-03-224-48/+84
| | | | | | | | | | | | | | | | | | Summary: Depending on C++11 <system_error> introduces a link-time requirement to C++11 symbols. Removing it allows us to depend on header-only C++11 and up libraries. Partially fixes http://llvm.org/PR32274 -- we know there's more invasive work to be done, but we're doing it incrementally. Reviewers: dblaikie, kpw, pelikan Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D31233 llvm-svn: 298480
* [XRay][compiler-rt] Add missing include to <string>Dean Michael Berris2017-03-171-0/+1
| | | | | | | Fixes a build break when using clang-3.9.1 (reported upstream, post-commit review of D30850). llvm-svn: 298039
* [XRay][compiler-rt] Add missing include for <functional>Dean Michael Berris2017-03-171-0/+1
| | | | | | Fixes http://llvm.org/PR32313 llvm-svn: 298037
* Add NO_EXEC_STACK_DIRECTIVE to xray assembly files.Dean Michael Berris2017-03-153-0/+12
| | | | | | | | | | | | | | Summary: Add NO_EXEC_STACK_DIRECTIVE to xray assembly files Reviewers: dberris, javed.absar Reviewed By: dberris Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D30953 llvm-svn: 297894
* [XRay] [compiler-rt] Refactor logic for xray fdr logging. NFC.Dean Michael Berris2017-03-156-394/+891
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Separated the IO and the thread local storage state machine of logging from the writing of log records once the contents are deterministic. Finer granularity functions are provided as inline functions in the same header such that stack does not grow due to the functions being separated. An executable utility xray_fdr_log_printer is also implemented to use the finest granularity functions to produce binary test data in the FDR format with a relatively convenient text input. For example, one can take a file with textual contents layed out in rows and feed it to the binary to generate data that llvm-xray convert can then read. This is a convenient way to build a test suite for llvm-xray convert to ensure it's robust to the fdr format. Example: $cat myFile.txt NewBuffer : { time = 2 , Tid=5} NewCPU : { CPU =1 , TSC = 123} Function : { FuncId = 5, TSCDelta = 3, EntryType = Entry } Function : { FuncId = 5, TSCDelta = 5, EntryType = Exit} TSCWrap : { TSC = 678 } Function : { FuncId = 6, TSCDelta = 0, EntryType = Entry } Function : { FuncId = 6, TSCDelta = 50, EntryType = Exit } EOB : { } $cat myFile.txt | ./bin/xray_fdr_log_printer > /tmp/binarydata.bin $./bin/llvm-xray convert -output-format=yaml -output=- /tmp/binarydata.bin yaml format comes out as expected. Reviewers: dberris, pelikan Reviewed By: dberris Subscribers: llvm-commits, mgorny Differential Revision: https://reviews.llvm.org/D30850 llvm-svn: 297801
* [XRay][compiler-rt] Support TSC emulation even for x86_64Dean Michael Berris2017-03-152-14/+37
| | | | | | | | | | | | | | | | | | | Summary: Use TSC emulation in cases where RDTSCP isn't available on the host running an XRay instrumented binary. We can then fall back into emulation instead of not even installing XRay's runtime functionality. We only do this for now in the naive/basic logging implementation, but should be useful in even FDR mode. Should fix http://llvm.org/PR32148. Reviewers: pelikan, rnk, sdardis Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D30677 llvm-svn: 297800
* Fix a build break with xrayDean Michael Berris2017-03-141-0/+1
| | | | | | | | | | | | Summary: Building compiler-rt with clang 3.7 broken, could not find mkstemp Reviewers: dberris, bkramer Reviewed By: dberris Differential Revision: https://reviews.llvm.org/D30389 llvm-svn: 297794
* [XRay] [compiler-rt] Stub out architectures we don't do arg1 logging on.Tim Shen2017-03-063-5/+20
| | | | | | | | | | | | rL297000 forgot to include code for three architectures that appeared since I wrote the first version. This gives them the same treatment as ARMs have for now - write stubs and wait for someone to actually implement it. Patched by pelikan (Martin Pelikán)! Differential Revision: https://reviews.llvm.org/D30634 llvm-svn: 297003
* [XRay] [compiler-rt] Allow logging the first argument of a function call.Dean Michael Berris2017-03-067-11/+85
| | | | | | | | | | | | | | | | | | | 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] [NFC] Annotate unused variables for the compiler.Dean Michael Berris2017-02-282-2/+2
| | | | | | | | | | | | | | | | | Summary: Use a common definition of a "this variable is unused" annotation for useless variables only present for their lambda global initializers, to silence gcc's warning. Reviewers: dberris Reviewed By: dberris Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D29860 llvm-svn: 296449
* [XRay][compiler-rt] Switch default XRay 'patch_premain' to falseDean Michael Berris2017-02-281-1/+1
| | | | | | | | | | | | | | | | | | | | | | 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
* [xray] Unbreak unittest after r295967.Benjamin Kramer2017-02-231-2/+2
| | | | llvm-svn: 295969
* [Xray] fix building the runtime with GCC.Benjamin Kramer2017-02-232-18/+21
| | | | | | | GCC has a warning about enum bitfields that cannot be disabled. Do the ugly thing and go through uint8_t for all the values. llvm-svn: 295967
* [XRay] Change the ppc trampoline asm file into a different name, to not ↵Tim Shen2017-02-222-1/+1
| | | | | | collide with the cc file. NFC. llvm-svn: 295795
* [XRay][compiler-rt] Allow for defining defaults at compile-timeDean Michael Berris2017-02-181-1/+25
| | | | | | | | | | | | | | | | | | | | | | Summary: Currently, defaulted options cannot be overriden easily. As an example, we always patch the binary pre-main unless the user defines the option at the commandline to inhibit this behaviour. This change allows for building different versions of the XRay archive with different defaults (whether to patch pre-main, or whether to use FDR mode by default, etc.) and giving that choice at link-time. For now we don't create different archives that have different defaults, but those could be added in later revisions. This change just enables the possibility. Reviewers: pelikan, kcc Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D30022 llvm-svn: 295534
* Re-commit r295017, since we have a potential fix of the tests, r295248, landed.Tim Shen2017-02-157-0/+328
| | | | | | Differential Revision: https://reviews.llvm.org/D29742 llvm-svn: 295251
OpenPOWER on IntegriCloud