summaryrefslogtreecommitdiffstats
path: root/llvm/lib/XRay
Commit message (Collapse)AuthorAgeFilesLines
* [cmake] Explicitly mark libraries defined in lib/ as "Component Libraries"Tom Stellard2019-11-211-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Most libraries are defined in the lib/ directory but there are also a few libraries defined in tools/ e.g. libLLVM, libLTO. I'm defining "Component Libraries" as libraries defined in lib/ that may be included in libLLVM.so. Explicitly marking the libraries in lib/ as component libraries allows us to remove some fragile checks that attempt to differentiate between lib/ libraries and tools/ libraires: 1. In tools/llvm-shlib, because llvm_map_components_to_libnames(LIB_NAMES "all") returned a list of all libraries defined in the whole project, there was custom code needed to filter out libraries defined in tools/, none of which should be included in libLLVM.so. This code assumed that any library defined as static was from lib/ and everything else should be excluded. With this change, llvm_map_components_to_libnames(LIB_NAMES, "all") only returns libraries that have been added to the LLVM_COMPONENT_LIBS global cmake property, so this custom filtering logic can be removed. Doing this also fixes the build with BUILD_SHARED_LIBS=ON and LLVM_BUILD_LLVM_DYLIB=ON. 2. There was some code in llvm_add_library that assumed that libraries defined in lib/ would not have LLVM_LINK_COMPONENTS or ARG_LINK_COMPONENTS set. This is only true because libraries defined lib lib/ use LLVMBuild.txt and don't set these values. This code has been fixed now to check if the library has been explicitly marked as a component library, which should now make it easier to remove LLVMBuild at some point in the future. I have tested this patch on Windows, MacOS and Linux with release builds and the following combinations of CMake options: - "" (No options) - -DLLVM_BUILD_LLVM_DYLIB=ON - -DLLVM_LINK_LLVM_DYLIB=ON - -DBUILD_SHARED_LIBS=ON - -DBUILD_SHARED_LIBS=ON -DLLVM_BUILD_LLVM_DYLIB=ON - -DBUILD_SHARED_LIBS=ON -DLLVM_LINK_LLVM_DYLIB=ON Reviewers: beanz, smeenai, compnerd, phosek Reviewed By: beanz Subscribers: wuzish, jholewinski, arsenm, dschuff, jyknight, dylanmckay, sdardis, nemanjai, jvesely, nhaehnle, mgorny, mehdi_amini, sbc100, jgravelle-google, hiraditya, aheejin, fedor.sergeev, asb, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, jrtc27, MaskRay, zzheng, edward-jones, atanasyan, steven_wu, rogfer01, MartinMosbeck, brucehoult, the_o, dexonsmith, PkmX, jocewei, jsji, dang, Jim, lenary, s.egerton, pzheng, sameer.abuasal, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D70179
* [llvm-xray] Add AArch64 to llvm-xray extractAditya Kumar2019-11-081-5/+17
| | | | | | | | | This required adding support for resolving R_AARCH64_ABS64 relocations to get accurate addresses for function names to resolve. Authored by: ianlevesque (Ian Levesque) Reviewers: dberris, phosek, smeenai, tetsuo-cpp Differential Revision: https://reviews.llvm.org/D69967
* [XRay] Silence static analyzer dyn_cast<BufferExtents> null dereference ↵Simon Pilgrim2019-09-221-1/+1
| | | | | | warning. NFCI. llvm-svn: 372520
* [llvm] Migrate llvm::make_unique to std::make_uniqueJonas Devlieghere2019-08-151-12/+12
| | | | | | | | Now that we've moved to C++14, we no longer need the llvm::make_unique implementation from STLExtras.h. This patch is a mechanical replacement of (hopefully) all the llvm::make_unique instances across the monorepo. llvm-svn: 369013
* Recommit r368812 "[llvm/Object] - Convert SectionRef::getName() to return ↵George Rimar2019-08-141-4/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Expected<>" Changes: no changes. A fix for the clang code will be landed right on top. Original commit message: SectionRef::getName() returns std::error_code now. Returning Expected<> instead has multiple benefits. For example, it forces user to check the error returned. Also Expected<> may keep a valuable string error message, what is more useful than having a error code. (Object\invalid.test was updated to show the new messages printed.) This patch makes a change for all users to switch to Expected<> version. Note: in a few places the error returned was ignored before my changes. In such places I left them ignored. My intention was to convert the interface used, and not to improve and/or the existent users in this patch. (Though I think this is good idea for a follow-ups to revisit such places and either remove consumeError calls or comment each of them to clarify why it is OK to have them). Differential revision: https://reviews.llvm.org/D66089 llvm-svn: 368826
* Revert r368812 "[llvm/Object] - Convert SectionRef::getName() to return ↵George Rimar2019-08-141-5/+4
| | | | | | | | Expected<>" It broke clang BB: http://lab.llvm.org:8011/builders/clang-x86_64-debian-fast/builds/16455 llvm-svn: 368813
* [llvm/Object] - Convert SectionRef::getName() to return Expected<>George Rimar2019-08-141-4/+5
| | | | | | | | | | | | | | | | | | | | | | | SectionRef::getName() returns std::error_code now. Returning Expected<> instead has multiple benefits. For example, it forces user to check the error returned. Also Expected<> may keep a valuable string error message, what is more useful than having a error code. (Object\invalid.test was updated to show the new messages printed.) This patch makes a change for all users to switch to Expected<> version. Note: in a few places the error returned was ignored before my changes. In such places I left them ignored. My intention was to convert the interface used, and not to improve and/or the existent users in this patch. (Though I think this is good idea for a follow-ups to revisit such places and either remove consumeError calls or comment each of them to clarify why it is OK to have them). Differential revision: https://reviews.llvm.org/D66089 llvm-svn: 368812
* Switch LLVM to use 64-bit offsets (2/5)Igor Kudrin2019-08-066-131/+157
| | | | | | | | | This updates all libraries and tools in LLVM Core to use 64-bit offsets which directly or indirectly come to DataExtractor. Differential Revision: https://reviews.llvm.org/D65638 llvm-svn: 368014
* Open native file handles to avoid converting from FDs, NFCReid Kleckner2019-07-113-19/+21
| | | | | | Follow up to r365588. llvm-svn: 365820
* [Support] Move llvm::MemoryBuffer to sys::fs::file_tReid Kleckner2019-07-103-3/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: On Windows, Posix integer file descriptors are a compatibility layer over native file handles provided by the C runtime. There is a hard limit on the maximum number of file descriptors that a process can open, and the limit is 8192. LLD typically doesn't run into this limit because it opens input files, maps them into memory, and then immediately closes the file descriptor. This prevents it from running out of FDs. For various reasons, I'd like to open handles to every input file and keep them open during linking. That requires migrating MemoryBuffer over to taking open native file handles instead of integer FDs. Reviewers: aganea, Bigcheese Reviewed By: aganea Subscribers: smeenai, silvas, mehdi_amini, hiraditya, steven_wu, dexonsmith, dang, llvm-commits, zturner Tags: #llvm Differential Revision: https://reviews.llvm.org/D63453 llvm-svn: 365588
* [CMake] Delete redundant DEPENDS/LINK_LIBS from LineEditor/XRayFangrui Song2019-06-221-8/+0
| | | | | | The link dependencies are already specified in LLVMBuild.txt llvm-svn: 364125
* Recommit [Object] Change object::SectionRef::getContents() to return ↵Fangrui Song2019-05-161-3/+4
| | | | | | | | | | | | Expected<StringRef> r360876 didn't fix 2 call sites in clang. Expected<ArrayRef<uint8_t>> may be better but use Expected<StringRef> for now. Follow-up of D61781. llvm-svn: 360892
* Revert r360876 "[Object] Change object::SectionRef::getContents() to return ↵Hans Wennborg2019-05-161-4/+3
| | | | | | | | | | | | Expected<StringRef>" It broke the Clang build, see llvm-commits thread. > Expected<ArrayRef<uint8_t>> may be better but use Expected<StringRef> for now. > > Follow-up of D61781. llvm-svn: 360878
* [Object] Change object::SectionRef::getContents() to return Expected<StringRef>Fangrui Song2019-05-161-3/+4
| | | | | | | | Expected<ArrayRef<uint8_t>> may be better but use Expected<StringRef> for now. Follow-up of D61781. llvm-svn: 360876
* Use llvm::stable_sortFangrui Song2019-04-231-4/+3
| | | | | | While touching the code, simplify if feasible. llvm-svn: 358996
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-1915-60/+45
| | | | | | | | | | | | | | | | | to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
* [Object] Rename getRelrRelocationType to getRelativeRelocationTypeFangrui Song2018-12-141-6/+6
| | | | | | | | | | | | | | | | | Summary: The two utility functions were added in D47919 to support SHT_RELR. However, these are just relative relocations types and are't necessarily be named Relr. Reviewers: phosek, dberris Reviewed By: dberris Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D55691 llvm-svn: 349133
* [llvm-xray] Use correct variable namePetr Hosek2018-12-141-2/+2
| | | | | | This fixes the compiler error introduced in r349129. llvm-svn: 349130
* [llvm-xray] Store offset pointers in temporariesPetr Hosek2018-12-141-2/+4
| | | | | | | | | | DataExtractor::getU64 modifies the OffsetPtr which also pass to RelocateOrElse which breaks on Windows. This addresses the issue introduced in r349120. Differential Revision: https://reviews.llvm.org/D55689 llvm-svn: 349129
* [llvm-xray] Support for PIEPetr Hosek2018-12-141-2/+41
| | | | | | | | | | When the instrumented binary is linked as PIE, we need to apply the relative relocations to sleds. This is handled by the dynamic linker at runtime, but when processing the file we have to do it ourselves. Differential Revision: https://reviews.llvm.org/D55542 llvm-svn: 349120
* [XRay] Improve FDR trace handling and error messagingDean Michael Berris2018-11-094-23/+188
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This change covers a number of things spanning LLVM and compiler-rt, which are related in a non-trivial way. In LLVM, we have a library that handles the FDR mode even log loading, which uses C++'s runtime polymorphism feature to better faithfully represent the events that are written down by the FDR mode runtime. We do this by interpreting a trace that's serliased in a common format agreed upon by both the trace loading library and the FDR mode runtime. This library is under active development, which consists of features allowing us to reconstitute a higher-level event log. This event log is used by the conversion and visualisation tools we have for interpreting XRay traces. One of the tools we have is a diagnostic tool in llvm-xray called `fdr-dump` which we've been using to debug our expectations of what the FDR runtime should be writing and what the logical FDR event log structures are. We use this fairly extensively to reason about why some non-trivial traces we're generating with FDR mode runtimes fail to convert or fail to parse correctly. One of these failures we've found in manual debugging of some of the traces we've seen involve an inconsistency between the buffer extents (a record indicating how many bytes to follow are part of a logical thread's event log) and the record of the bytes written into the log -- sometimes it turns out the data could be garbage, due to buffers being recycled, but sometimes we're seeing the buffer extent indicating a log is "shorter" than the actual records associated with the buffer. This case happens particularly with function entry records with a call argument. This change for now updates the FDR mode runtime to write the bytes for the function call and arg record before updating the buffer extents atomically, allowing multiple threads to see a consistent view of the data in the buffer using the atomic counter associated with a buffer. What we're trying to prevent here is partial updates where we see the intermediary updates to the buffer extents (function record size then call argument record size) becoming observable from another thread, for instance, one doing the serialization/flushing. To do both diagnose this issue properly, we need to be able to honour the extents being set in the `BufferExtents` records marking the beginning of the logical buffers when reading an FDR trace. Since LLVM doesn't use C++'s RTTI mechanism, we instead follow the advice in the documentation for LLVM Style RTTI (https://llvm.org/docs/HowToSetUpLLVMStyleRTTI.html). We then rely on this RTTI feature to ensure that our file-based record producer (our streaming "deserializer") can honour the extents of individual buffers as we interpret traces. This also sets us up to be able to eventually do smart skipping/continuation of FDR logs, seeking instead to find BufferExtents records in cases where we find potentially recoverable errors. In the meantime, we make this change to operate in a strict mode when reading logical buffers with extent records. Reviewers: mboerger Subscribers: hiraditya, llvm-commits, jfb Differential Revision: https://reviews.llvm.org/D54201 llvm-svn: 346473
* [XRay] Clean up more std::copy(...)'sDean Michael Berris2018-11-071-4/+2
| | | | | | Update a couple more places to use conversion from StringRef to string. llvm-svn: 346306
* [XRay] Use explicit string conversionDean Michael Berris2018-11-071-2/+1
| | | | | | | Instead of using std::copy(...), use a conversion to string instead from StringRef to std::string. llvm-svn: 346304
* [XRay] Use TSC delta encoding for custom/typed eventsDean Michael Berris2018-11-0711-12/+233
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This change updates the version number for FDR logs to 5, and update the trace processing to support changes in the custom event records. In the runtime, since we're already writing down the record preamble to handle CPU migrations and TSC wraparound, we can use the same TSC delta encoding in the custom event and typed event records that we use in function event records. We do the same change to typed events (which were unsupported before this change in the trace processing) which now show up in the trace. Future changes should increase our testing coverage to make custom and typed events as first class entities in the FDR mode log processing tools. This change is also a good example of how we end up supporting new record types in the FDR mode implementation. This shows the places where new record types are added and supported. Depends on D54139. Reviewers: mboerger Subscribers: hiraditya, arphaman, jfb, llvm-commits Differential Revision: https://reviews.llvm.org/D54140 llvm-svn: 346293
* [XRay] Update XRayRecord to support Custom/Typed EventsDean Michael Berris2018-11-064-7/+28
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: This change cuts across LLVM and compiler-rt to add support for rendering custom events in the XRayRecord type, to allow for including user-provided annotations in the output YAML (as raw bytes). This work enables us to add custom event and typed event records into the `llvm::xray::Trace` type for user-provided events. This can then be programmatically handled through the C++ API and can be included in some of the tooling as well. For now we support printing the raw data we encounter in the custom events in the converted output. Future work will allow us to start interpreting these custom and typed events through a yet-to-be-defined API for extending the trace analysis library. Reviewers: mboerger Subscribers: hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D54139 llvm-svn: 346214
* [XRay] Update delta computations in runtimeDean Michael Berris2018-11-021-4/+4
| | | | | | | | | | | | | | | | | | Summary: Fix some issues discovered from mostly manual inspection of outputs from the `llvm-xray fdr-dump` tool. It turns out we haven't been writing the deltas properly, and have been writing down zeros for deltas of some records. This change fixes this oversight born by the recent refactoring. Reviewers: mboerger Subscribers: llvm-commits, hiraditya Differential Revision: https://reviews.llvm.org/D54022 llvm-svn: 345954
* [XRay] Fix TSC and atomic custom/typed event accountingDean Michael Berris2018-11-011-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This is a follow-on change to D53858 which turns out to have had a TSC accounting bug when writing out function exit records in FDR mode. This change adds a number of tests to ensure that: - We are handling the delta between the exit TSC and the last TSC we've seen. - We are writing the custom event and typed event records as a single update to the buffer extents. - We are able to catch boundary conditions when loading FDR logs. We introduce a TSC matcher to the test helpers, which we use in the testing/verification of the TSC accounting change. Reviewers: mboerger Subscribers: mgorny, hiraditya, jfb, llvm-commits Differential Revision: https://reviews.llvm.org/D53967 llvm-svn: 345905
* [XRay] Add CPU ID in Custom Event FDR RecordsDean Michael Berris2018-11-015-14/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This change cuts across compiler-rt and llvm, to increment the FDR log version number to 4, and include the CPU ID in the custom event records. This is a step towards allowing us to change the `llvm::xray::Trace` object to start representing both custom and typed events in the stream of records. Follow-on changes will allow us to change the kinds of records we're presenting in the stream of traces, to incorporate the data in custom/typed events. A follow-on change will handle the typed event case, where it may not fit within the 15-byte buffer for metadata records. This work is part of the larger effort to enable writing analysis and processing tools using a common in-memory representation of the events found in traces. The work will focus on porting existing tools in LLVM to use the common representation and informing the design of a library/framework for expressing trace event analysis as C++ programs. Reviewers: mboerger, eizan Subscribers: hiraditya, mgrang, llvm-commits Differential Revision: https://reviews.llvm.org/D53920 llvm-svn: 345798
* [XRay] Use std::errc::invalid_argument instead of std::errc::bad_messageYi Kong2018-10-261-14/+14
| | | | | | | | | | This change should appease the mingw32 builds. Similar to r293725. Differential Revision: https://reviews.llvm.org/D53742 llvm-svn: 345416
* Use the container form llvm::sort(C, ...)Fangrui Song2018-09-301-1/+1
| | | | | | | There are a few leftovers in rL343163 which span two lines. This commit changes these llvm::sort(C.begin(), C.end, ...) to llvm::sort(C, ...) llvm-svn: 343426
* [XRay] Clean up XRay build configurationDean Michael Berris2018-09-241-0/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This change spans both LLVM and compiler-rt, where we do the following: - Add XRay to the LLVMBuild system, to allow for distributing the XRay trace loading library along with the LLVM distributions. - Use `llvm-config` better in the compiler-rt XRay implementation, to depend on the potentially already-distributed LLVM XRay library. While this is tested with the standalone compiler-rt build, it does require that the LLVMXRay library (and LLVMSupport as well) are available during the build. In case the static libraries are available, the unit tests will build and work fine. We're still having issues with attempting to use a shared library version of the LLVMXRay library since the shared library might not be accessible from the standard shared library lookup paths. The larger change here is the inclusion of the LLVMXRay library in the distribution, which allows for building tools around the XRay traces and profiles that the XRay runtime already generates. Reviewers: echristo, beanz Subscribers: mgorny, hiraditya, mboerger, llvm-commits Differential Revision: https://reviews.llvm.org/D52349 llvm-svn: 342859
* [XRay] Bug fixes for FDR custom event and arg-loggingDean Michael Berris2018-09-132-21/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This change has a number of fixes for FDR mode in compiler-rt along with changes to the tooling handling the traces in llvm. In the runtime, we do the following: - Advance the "last record" pointer appropriately when writing the custom event data in the log. - Add XRAY_NEVER_INSTRUMENT in the rewinding routine. - When collecting the argument of functions appropriately marked, we should not attempt to rewind them (and reset the counts of functions that can be re-wound). In the tooling, we do the following: - Remove the state logic in BlockIndexer and instead rely on the presence/absence of records to indicate blocks. - Move the verifier into a loop associated with each block. Reviewers: mboerger, eizan Subscribers: llvm-commits, hiraditya Differential Revision: https://reviews.llvm.org/D51965 llvm-svn: 342122
* [XRay] Ensure lambda outlives llvm::function_refDean Michael Berris2018-09-111-2/+2
| | | | | | Follow-up to D51912. llvm-svn: 341912
* [XRay] Write the TSC along with CPUIDDean Michael Berris2018-09-111-1/+1
| | | | | | | | Fixes builds in non-little-endian systems. This is a follow-up to D51911. llvm-svn: 341909
* [XRay] Use FDR Records+Visitors for Trace LoadingDean Michael Berris2018-09-114-545/+167
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: In this change, we overhaul the implementation for loading `llvm::xray::Trace` objects from files by using the combination of specific FDR Record types and visitors breaking up the logic to reconstitute an execution trace from flight-data recorder mode traces. This change allows us to handle out-of-temporal order blocks as written in files, and more consistently recreate an execution trace spanning multiple blocks and threads. To do this, we use the `WallclockRecord` associated with each block to maintain temporal order of blocks, before attempting to recreate an execution trace. The new addition in this change is the `TraceExpander` type which can be thought of as a decompression/decoding routine. This allows us to maintain the state of an execution environment (thread+process) and create `XRayRecord` instances that fit nicely into the `Trace` container. We don't have a specific unit test for the TraceExpander type, since the end-to-end tests for the `llvm-xray convert` tools already cover precisely this codepath. This change completes the refactoring started with D50441. Depends on D51911. Reviewers: mboerger, eizan Subscribers: mgorny, hiraditya, mgrang, llvm-commits Differential Revision: https://reviews.llvm.org/D51912 llvm-svn: 341906
* [XRay] Add TSC to NewCPUId RecordsDean Michael Berris2018-09-112-2/+9
| | | | | | | | | | | | | | | Summary: This more correctly reflects the data written by the FDR mode runtime. This is a continuation of the work in D50441. Reviewers: mboerger, eizan Subscribers: hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D51911 llvm-svn: 341905
* [XRay] Add the `llvm-xray fdr-dump` implementationDean Michael Berris2018-09-112-0/+97
| | | | | | | | | | | | | | | | | | | Summary: In this change, we implement a `BlockPrinter` which orders records in a Block that's been indexed by the `BlockIndexer`. This is used in the `llvm-xray fdr-dump` tool which ties together the various types and utilities we've been working on, to allow for inspection of XRay FDR mode traces both with and without verification. This change is the final step of the refactoring of D50441. Reviewers: mboerger, eizan Subscribers: mgorny, hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D51846 llvm-svn: 341887
* [Xray] tooling allow MachO format supportDavid Carlier2018-09-101-4/+4
| | | | | | | | | | | | Getting writable xray __DATA sections from MachO as well. Reviewers: dberris Reviewed By: dberris Differential Revision: https://reviews.llvm.org/D51758 llvm-svn: 341772
* [XRay] Remove unused referenceDean Michael Berris2018-09-101-2/+2
| | | | | | | | The reference was only used in the assertion. Follow-up on D51723. llvm-svn: 341771
* [XRay] Add a BlockVerifier visitor for FDR RecordsDean Michael Berris2018-09-102-0/+188
| | | | | | | | | | | | | | | | | | | | | | Summary: This patch implements a `BlockVerifier` type which enforces the invariants of the log structure of FDR mode logs on a per-block basis. This ensures that the data we encounter from an FDR mode log semantically correct (i.e. that records follow the documented "grammar" for FDR mode log records). This is another part of the refactoring of D50441. This is a slightly modified version of rL341628, avoiding the `std::tuple<...>` constructor that is not constexpr in C++11. Reviewers: mboerger, eizan Subscribers: mgorny, hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D51723 llvm-svn: 341769
* Revert "[XRay] Add a BlockVerifier visitor for FDR Records"Dean Michael Berris2018-09-072-183/+0
| | | | | | This reverts commit r341628. llvm-svn: 341631
* [XRay] Add a BlockVerifier visitor for FDR RecordsDean Michael Berris2018-09-072-0/+183
| | | | | | | | | | | | | | | | | | | Summary: This patch implements a `BlockVerifier` type which enforces the invariants of the log structure of FDR mode logs on a per-block basis. This ensures that the data we encounter from an FDR mode log semantically correct (i.e. that records follow the documented "grammar" for FDR mode log records). This is another part of the refactoring of D50441. Reviewers: mboerger, eizan Subscribers: mgorny, hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D51723 llvm-svn: 341628
* Remove unnecessary semicolon to silence -Wpedantic warning. NFCI.Simon Pilgrim2018-09-061-1/+1
| | | | llvm-svn: 341555
* [XRay] Add a BlockIndexer visitor for FDR Records.Dean Michael Berris2018-09-062-0/+98
| | | | | | | | | | | | | | | | | | | | | | | Summary: This change adds a `BlockIndexer` type which maintains pointers to records that belong to the same process+thread pairs. The indexing happens with order of appearance of records as they are visited. This version of the indexer currently only supports FDR version 3 logs, which contain `BufferExtent` records. We will add support for v2 and v1 logs in follow-up patches. This is another part of D50441. Reviewers: eizan, kpw, mboerger Reviewed By: mboerger Subscribers: mboerger, mgorny, hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D51673 llvm-svn: 341518
* [XRay] Add a RecordPrinter visitor for FDR RecordsDean Michael Berris2018-09-052-0/+90
| | | | | | | | | | | | | | | | | Summary: This change adds a `RecordPrinter` type which does some basic text serialization of the FDR record instances. This is one component of the tool we're building to dump the records from an FDR mode log as-is. This is a small part of D50441. Reviewers: eizan, kpw Subscribers: mgorny, hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D51672 llvm-svn: 341447
* [XRay] Update RecordInitializer for PIDRecordDean Michael Berris2018-08-311-1/+1
| | | | | | | | Since we changed the storage for the PID in PIDRecord instances, we need to also update the way we load the data from a DataExtractor through the RecordInitializer. llvm-svn: 341243
* [XRay] Use correct type for PID recordsDean Michael Berris2018-08-311-1/+1
| | | | | | | | | Previously we've been reading and writing the wrong types which only worked in little endian implementations. This time we're writing the same typed values the runtime is using, and reading them appropriately as well. llvm-svn: 341241
* [XRay] Use correct type for thread ID parsingDean Michael Berris2018-08-311-3/+3
| | | | | | | Previously we were reading only a uint16_t when we really needed to read an int32_t from the log. llvm-svn: 341239
* [XRay] Change function record reader to be endian-awareDean Michael Berris2018-08-311-12/+13
| | | | | | | | | | | | | | | | | This change allows us to let the compiler do the right thing for when handling big-endian and little-endian records for FDR mode function records. Previously, we assumed that the encoding was little-endian that reading the first byte to look for the function id and function record types was ordered in a little-endian manner. This change allows us to better handle function records where the first four bytes may actually be encoded in big-endian thus giving us the wrong bytes where we're seeking the function information from. This is a follow-up to D51210 and D51289. llvm-svn: 341236
* [XRay] Fix FunctionRecord serializationDean Michael Berris2018-08-311-30/+9
| | | | | | | | | | | This change makes the writer implementation more consistent with the way fields are written down to avoid assumptions on bitfield order and padding. We also fix an inconsistency between the type returned by the `delta()` accessor to match the data member it's returning. This is a follow-up to D51289 and D51210. llvm-svn: 341230
OpenPOWER on IntegriCloud