3 Commits

Author	SHA1	Message	Date
Dean Michael Berris	5de005fa93	[XRay] Improve FDR trace handling and error messaging ... 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 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@346473 91177308-0d34-0410-b5e6-96231b3b80d8	2018-11-09 06:26:48 +00:00
Dean Michael Berris	8fa10fd67f	[XRay] Use TSC delta encoding for custom/typed events ... 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 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@346293 91177308-0d34-0410-b5e6-96231b3b80d8	2018-11-07 04:37:42 +00:00
Dean Michael Berris	20baaad0f3	[XRay] FDRTraceWriter and FDR Trace Loading ... Summary: This is the first step in the larger refactoring and reduction of D50441. This step in the process does the following: - Introduces more granular types of `Record`s representing the many kinds of records written/read by the Flight Data Recorder (FDR) mode `Trace` loading function(s). - Introduces an abstract `RecordVisitor` type meant to handle the processing of the various `Record` derived types. This `RecordVisitor` has two implementations in this patch: `RecordInitializer` and `FDRTraceWriter`. - We also introduce a convenience interface for building a collection of `Record` instances called a `LogBuilder`. This allows us to generate sequences of `Record` instances manually (used in unit tests but useful otherwise). - The`FDRTraceWriter` class implements the `RecordVisitor` interface and handles the writing of metadata records to a `raw_ostream`. We demonstrate that in the unit test, we can generate in-memory FDR mode traces using the specific `Record` derived types, which we load through the `loadTrace(...)` function yielding valid `Trace` objects. This patch introduces the required types and concepts for us to start replacing the logic implemented in the `loadFDRLog` function to use the more granular types. In subsequent patches, we will introduce more visitor implementations which isolate the verification, printing, indexing, production/consumption, and finally the conversion of the FDR mode logs. The overarching goal of these changes is to make handling FDR mode logs better tested, more understandable, more extensible, and more systematic. This will also allow us to better represent the execution trace, as we improve the fidelity of the events we represent in an XRay `Trace` object, which we intend to do after FDR mode log processing is in better shape. Reviewers: eizan Reviewed By: eizan Subscribers: mgorny, hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D51210 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@341029 91177308-0d34-0410-b5e6-96231b3b80d8	2018-08-30 07:22:21 +00:00