This is an archive of the discontinued LLVM Phabricator instance.

[XRay][compiler-rt] Support in-memory processing of FDR mode logs
ClosedPublic

Authored by dberris on May 8 2018, 4:19 AM.

Details

Summary

This change allows for handling the in-memory data associated with the
FDR mode implementation through the new __xray_log_process_buffers
API. With this change, we can now allow users to process the data
in-memory of the process instead of through writing files.

This for example allows users to stream the data of the FDR logging
implementation through network sockets, or through other mechanisms
instead of saving them to local files.

We introduce an FDR-specific flag, for "no_file_flush" which lets the
flushing logic skip opening/writing to files.

This option can be defaulted to true when building the compiler-rt
XRay runtime through the XRAY_FDR_OPTIONS preprocessor macro.

Event Timeline

dberris created this revision.May 8 2018, 4:19 AM
dberris updated this revision to Diff 146276.May 10 2018, 8:55 PM

Rebase and minor change to ==/!= implementation.

kpw accepted this revision.May 13 2018, 1:18 PM
kpw added inline comments.
compiler-rt/lib/xray/xray_buffer_queue.h
75

I have to ask. Why do you prefer this style where reference and pointer qualifiers are detached from the type they qualify? I understand the logic of grouping them with a variable name instead of a type, but choosing to group them to a function name baffles me.

97

Why DCHECK here instead of including this in the equality condition? I guess different views into the same Buffers are prohibited for now but this seems more fragile than it has to be.

compiler-rt/lib/xray/xray_fdr_logging.cc
74–76

Can you call this something like "nextBuffer" or "fdrNextBuffer" and write the comment so that it explains how it's supposed to be called? E.g. first call with a zero initialized XRayBuffer, then subsequent calls hand back the current XRayBuffer to advance forward.

Actually, since this maintains static iterators, you could keep static state about whether the header was returned and get rid of the parameter entirely if you choose. Although, you may need a way to reset the iterators, which is currently encoded in checks of the parameter.

Edit: It looks like this shouldn't be renamed since it's the function pointer installed by the __xray_log_set_buffer_iterator(). I still think explaining the usages and/or the assumptions about the state transitions is a good idea.

464–465

Why did you invert this condition?

compiler-rt/test/xray/TestCases/Posix/fdr-mode-inmemory.cc
2

In case any DCHECK failures are encountered during test execution, that should be covered by buildbots that build LLVM in debug mode and run tests right?

47

Clever FileCheck to just rely on asserts instead of CHECK statements.

This revision is now accepted and ready to land.May 13 2018, 1:18 PM
dberris updated this revision to Diff 146536.May 13 2018, 8:36 PM
dberris marked 5 inline comments as done.
  • fixup: Address comments by kpw@.
compiler-rt/lib/xray/xray_buffer_queue.h
75

I don't -- clang-format does it for me. :)

97

This is a non-salient property of the type. This means, technically, the iterator which share the same base and offset compare equal to each other. Whether or not the bounds are the same don't determine whether two iterators are equal. The DCHECK is there precisely to only catch the case where the implementation has diverged from the intent, and only matters in cases where we want to catch that bug.

compiler-rt/lib/xray/xray_fdr_logging.cc
464–465

We change which flag(s) we're looking at in the fdr_impl header, which means we're consolidating the flags into the global fdrFlags() structure. This means we only change the FDR-specific implementation if there was no data in XRAY_FDR_OPTIONS, and revert to the data in the deprecated flags in XRAY_OPTIONS.

compiler-rt/test/xray/TestCases/Posix/fdr-mode-inmemory.cc
2

Yes.

This revision was automatically updated to reflect the committed changes.
Herald added a subscriber: Restricted Project. · View Herald TranscriptMay 13 2018, 8:38 PM