Commit Graph

92 Commits

Author SHA1 Message Date
Jonas Devlieghere 0eaee545ee [llvm] Migrate llvm::make_unique to std::make_unique
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
2019-08-15 15:54:37 +00:00
George Rimar bcc00e1afb Recommit r368812 "[llvm/Object] - Convert SectionRef::getName() to return 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
2019-08-14 11:10:11 +00:00
George Rimar 468919e182 Revert r368812 "[llvm/Object] - Convert SectionRef::getName() to return Expected<>"
It broke clang BB: http://lab.llvm.org:8011/builders/clang-x86_64-debian-fast/builds/16455

llvm-svn: 368813
2019-08-14 08:56:55 +00:00
George Rimar a0c6a35714 [llvm/Object] - Convert SectionRef::getName() to return Expected<>
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
2019-08-14 08:46:54 +00:00
Igor Kudrin f26a70a5e7 Switch LLVM to use 64-bit offsets (2/5)
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
2019-08-06 10:49:40 +00:00
Reid Kleckner f002fcb2ad Open native file handles to avoid converting from FDs, NFC
Follow up to r365588.

llvm-svn: 365820
2019-07-11 20:29:32 +00:00
Reid Kleckner cc418a3af4 [Support] Move llvm::MemoryBuffer to sys::fs::file_t
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
2019-07-10 00:34:13 +00:00
Fangrui Song 01d649c249 [CMake] Delete redundant DEPENDS/LINK_LIBS from LineEditor/XRay
The link dependencies are already specified in LLVMBuild.txt

llvm-svn: 364125
2019-06-22 01:50:21 +00:00
Fangrui Song e183340c29 Recommit [Object] Change object::SectionRef::getContents() to return 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
2019-05-16 13:24:04 +00:00
Hans Wennborg 4da9ff9fcf Revert r360876 "[Object] Change object::SectionRef::getContents() to return 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
2019-05-16 12:08:34 +00:00
Fangrui Song a076ec54be [Object] Change object::SectionRef::getContents() to return Expected<StringRef>
Expected<ArrayRef<uint8_t>> may be better but use Expected<StringRef> for now.

Follow-up of D61781.

llvm-svn: 360876
2019-05-16 11:33:48 +00:00
Fangrui Song efd94c56ba Use llvm::stable_sort
While touching the code, simplify if feasible.

llvm-svn: 358996
2019-04-23 14:51:27 +00:00
Chandler Carruth 2946cd7010 Update the file headers across all of the LLVM projects in the monorepo
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
2019-01-19 08:50:56 +00:00
Fangrui Song d2ed5be815 [Object] Rename getRelrRelocationType to getRelativeRelocationType
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
2018-12-14 07:46:58 +00:00
Petr Hosek 0c02306dbd [llvm-xray] Use correct variable name
This fixes the compiler error introduced in r349129.

llvm-svn: 349130
2018-12-14 06:06:19 +00:00
Petr Hosek 27e2f2014a [llvm-xray] Store offset pointers in temporaries
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
2018-12-14 05:56:20 +00:00
Petr Hosek 493a082483 [llvm-xray] Support for PIE
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
2018-12-14 01:37:56 +00:00
Dean Michael Berris da375a67f8 [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

llvm-svn: 346473
2018-11-09 06:26:48 +00:00
Dean Michael Berris 8cc5cf2ee9 [XRay] Clean up more std::copy(...)'s
Update a couple more places to use conversion from StringRef to string.

llvm-svn: 346306
2018-11-07 11:52:22 +00:00
Dean Michael Berris 140e76a1aa [XRay] Use explicit string conversion
Instead of using std::copy(...), use a conversion to string instead from
StringRef to std::string.

llvm-svn: 346304
2018-11-07 11:44:00 +00:00
Dean Michael Berris 59439dd069 [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

llvm-svn: 346293
2018-11-07 04:37:42 +00:00
Dean Michael Berris 25f8d204b8 [XRay] Update XRayRecord to support Custom/Typed Events
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
2018-11-06 08:51:37 +00:00
Dean Michael Berris 0c96ae3d6e [XRay] Update delta computations in runtime
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
2018-11-02 08:07:38 +00:00
Dean Michael Berris e8c650ab12 [XRay] Fix TSC and atomic custom/typed event accounting
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
2018-11-01 22:57:50 +00:00
Dean Michael Berris 6b67ff0300 [XRay] Add CPU ID in Custom Event FDR Records
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
2018-11-01 00:18:52 +00:00
Yi Kong f609590469 [XRay] Use std::errc::invalid_argument instead of std::errc::bad_message
This change should appease the mingw32 builds.

Similar to r293725.

Differential Revision: https://reviews.llvm.org/D53742

llvm-svn: 345416
2018-10-26 18:25:27 +00:00
Fangrui Song 3507c6e884 Use the container form llvm::sort(C, ...)
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
2018-09-30 22:31:29 +00:00
Dean Michael Berris f578aaa058 [XRay] Clean up XRay build configuration
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
2018-09-24 05:28:01 +00:00
Dean Michael Berris 90a46bdec2 [XRay] Bug fixes for FDR custom event and arg-logging
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
2018-09-13 09:25:42 +00:00
Dean Michael Berris 174d2cf771 [XRay] Ensure lambda outlives llvm::function_ref
Follow-up to D51912.

llvm-svn: 341912
2018-09-11 08:03:30 +00:00
Dean Michael Berris ec605d3846 [XRay] Write the TSC along with CPUID
Fixes builds in non-little-endian systems.

This is a follow-up to D51911.

llvm-svn: 341909
2018-09-11 07:27:59 +00:00
Dean Michael Berris 985c2b9226 [XRay] Use FDR Records+Visitors for Trace Loading
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
2018-09-11 06:45:59 +00:00
Dean Michael Berris d2c50408d4 [XRay] Add TSC to NewCPUId Records
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
2018-09-11 06:36:51 +00:00
Dean Michael Berris dd01efc56d [XRay] Add the `llvm-xray fdr-dump` implementation
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
2018-09-11 00:22:53 +00:00
David Carlier 07cc5a8df9 [Xray] tooling allow MachO format support
Getting writable xray __DATA sections from MachO as well.

Reviewers: dberris

Reviewed By: dberris

Differential Revision: https://reviews.llvm.org/D51758

llvm-svn: 341772
2018-09-10 05:00:43 +00:00
Dean Michael Berris f3a3679e72 [XRay] Remove unused reference
The reference was only used in the assertion.

Follow-up on D51723.

llvm-svn: 341771
2018-09-10 02:57:05 +00:00
Dean Michael Berris b082c36061 [XRay] Add a BlockVerifier visitor for FDR Records
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
2018-09-10 02:35:25 +00:00
Dean Michael Berris f904839144 Revert "[XRay] Add a BlockVerifier visitor for FDR Records"
This reverts commit r341628.

llvm-svn: 341631
2018-09-07 03:38:26 +00:00
Dean Michael Berris b9dd61c13c [XRay] Add a BlockVerifier visitor for FDR Records
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
2018-09-07 02:25:06 +00:00
Simon Pilgrim 6088e85177 Remove unnecessary semicolon to silence -Wpedantic warning. NFCI.
llvm-svn: 341555
2018-09-06 15:15:28 +00:00
Dean Michael Berris 02f097e122 [XRay] Add a BlockIndexer visitor for FDR Records.
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
2018-09-06 05:55:57 +00:00
Dean Michael Berris fbc59d92e6 [XRay] Add a RecordPrinter visitor for FDR Records
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
2018-09-05 06:57:23 +00:00
Dean Michael Berris f135ac4bbc [XRay] Update RecordInitializer for PIDRecord
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
2018-08-31 20:02:55 +00:00
Dean Michael Berris 4cae04873b [XRay] Use correct type for PID records
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
2018-08-31 19:32:46 +00:00
Dean Michael Berris 250c56d127 [XRay] Use correct type for thread ID parsing
Previously we were reading only a uint16_t when we really needed to read
an int32_t from the log.

llvm-svn: 341239
2018-08-31 19:11:19 +00:00
Dean Michael Berris 3fc4cbfe10 [XRay] Change function record reader to be endian-aware
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
2018-08-31 18:36:58 +00:00
Dean Michael Berris c1dceee50b [XRay] Fix FunctionRecord serialization
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
2018-08-31 17:49:59 +00:00
Dean Michael Berris 5b7548c653 [XRay] Make Trace loading endian-aware
This change makes the XRay Trace loading functions first use a
little-endian data extractor, then on failures try a big-endian data
extractor. Without this change, the trace loading facility will not work
with data written from a big-endian machine.

Follow-up to D51210 and D51289.

llvm-svn: 341226
2018-08-31 17:06:28 +00:00
Dean Michael Berris 98717978c9 [XRay] Make the FDRTraceWriter Endian-aware
Before this patch, the FDRTraceWriter would not take endianness into
account when writing data into the output stream.

This is a follow-up to D51289 and D51210.

llvm-svn: 341223
2018-08-31 16:08:38 +00:00
Dean Michael Berris fc774e29d2 [XRay] Remove array for Metadata Record Types
This simplifies the implementation of the metadata lookup by using
scoped enums, rather than using enum classes. This way we can get the
number-name mapping without having to resort to comments.

Follow-up to D51289.

llvm-svn: 341205
2018-08-31 11:41:08 +00:00