[PATCH] D27038: [XRay][compiler-rt] XRay Flight Data Recorder Mode
Dean Michael Berris via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Wed Jan 4 19:26:45 PST 2017
dberris added a comment.
Thanks @pelikan -- PTAL?
================
Comment at: include/xray/xray_records.h:45
+
+ // The current civiltime timestamp, as retrived from 'gettimeofday'. This
+ // allows readers of the file to determine when the file was created or
----------------
pelikan wrote:
> timespec comes from clock_gettime(2), gettimeofday(2) returns timeval which has microseconds (which are no good here).
This is fine, we use this at the header to indicate some rough time when a trace was created. It's not used anywhere else.
================
Comment at: lib/xray/xray_fdr_logging.cc:317
+ unsigned CPU;
+ uint64_t TSC = __rdtscp(&CPU);
+
----------------
pelikan wrote:
> I really don't see how this *ever* compiled because it isn't #included; it fails for me for native amd64 as well as cross armv7/v8. My recent refactoring introduced readTSC(&CPU) in xray_x86_64.h or xray_emulate_tsc.h respectively, please use that. The seven line #ifdef #include chain can probably be put into some (internal) header if it needs to be repeated twice (but doesn't have to).
Right -- this code was written before that refactoring. I'll do that now. FWIW, clang doesn't complain about this.
================
Comment at: lib/xray/xray_fdr_logging.h:37
+ // A MetadataRecord must always have a type of 1.
+ RecordType Type : 1;
+
----------------
pelikan wrote:
> In file included from /home/pelikan/src/llvm/projects/compiler-rt/lib/xray/xray_fdr_logging.cc:17:0:
> /home/pelikan/src/llvm/projects/compiler-rt/lib/xray/xray_fdr_logging.h:37:21: warning: ‘__xray::MetadataRecord::Type’ is too small to hold all values of ‘enum class __xray::RecordType’
> RecordType Type : 1;
> ^
> /home/pelikan/src/llvm/projects/compiler-rt/lib/xray/xray_fdr_logging.h:48:28: warning: ‘__xray::MetadataRecord::RecordKind’ is too small to hold all values of ‘enum class __xray::MetadataRecord::RecordKinds’
> RecordKinds RecordKind : 7; // Use 7 bits to identify this record type.
> ^
> /home/pelikan/src/llvm/projects/compiler-rt/lib/xray/xray_fdr_logging.h:56:21: warning: ‘__xray::FunctionRecord::Type’ is too small to hold all values of ‘enum class __xray::RecordType’
> RecordType Type : 1;
> ^
> /home/pelikan/src/llvm/projects/compiler-rt/lib/xray/xray_fdr_logging.h:62:28: warning: ‘__xray::FunctionRecord::RecordKind’ is too small to hold all values of ‘enum class __xray::FunctionRecord::RecordKinds’
> RecordKinds RecordKind : 3;
>
> Is this a gcc (6.3.0 used) bug?
Unsure whether this is a bug, but that's a good question. RecordType is an enum class whose base is an unsigned 8-bit integral type -- and only has two values. 1 bit ought to be enough, no?
================
Comment at: lib/xray/xray_inmemory_log.cc:92
thread_local static size_t Offset = 0;
- static int Fd = __xray_OpenLogFile();
+ static int Fd = []() {
+ int F = getLogFD();
----------------
pelikan wrote:
> Why is this going back into a lambda? I thought we wanted to separate hot code from one-off initialization for readability.
Ah, this was a bad merge. Fixed.
https://reviews.llvm.org/D27038
More information about the llvm-commits
mailing list