This is an archive of the discontinued LLVM Phabricator instance.

[XRay] [compiler-rt] Allow logging the first argument of a function call.
ClosedPublic

Authored by pelikan on Feb 7 2017, 9:46 PM.

Details

Summary

Functions with the LOG_ARGS_ENTRY sled kind at their beginning will be handled
in a way to (optionally) pass their first call argument to your logging handler.

For practical and performance reasons, only the first argument is supported, and
only up to 64 bits.

Diff Detail

Repository
rL LLVM

Event Timeline

pelikan created this revision.Feb 7 2017, 9:46 PM
dberris requested changes to this revision.Feb 8 2017, 11:31 PM
dberris added inline comments.
include/xray/xray_interface.h
26–27 ↗(On Diff #87590)

Use 3 instead (we don't have anything using 3 yet)?

lib/xray/xray_AArch64.cc
124–126 ↗(On Diff #87590)

I don't think this will work -- this will be mangled differently from an extern "C" { ... } function, which this may have to be to make the symbol consistent. This means you'd have to define that symbol outside the __xray namespace, and mark it exter "C" {...}. As in:

} // namespace __xray

extern "C" {
void __xray_ArgLoggerEntry() XRAY_NEVER_INSTRUMENT {
  // FIXME: ...
}
}
lib/xray/xray_arm.cc
160–162 ↗(On Diff #87590)

Same here.

lib/xray/xray_interface.cc
217 ↗(On Diff #87590)

I think it would be better to make this store a release, for a stronger guarantee.

This revision now requires changes to proceed.Feb 8 2017, 11:31 PM
pelikan updated this revision to Diff 90435.Mar 3 2017, 12:02 AM
pelikan edited edge metadata.
pelikan marked 4 inline comments as done.
  • fix number and extern "C" ARM's empty stubs
  • fix test
pelikan added inline comments.Mar 3 2017, 12:04 AM
lib/xray/xray_interface.cc
217 ↗(On Diff #87590)

Stronger guarantee of what? There's nothing we're synchronizing *with*, we only care about atomicity (which this provides). When I see a release/consume I automatically look for an acquire, and in this case there isn't one.

dberris added inline comments.Mar 3 2017, 12:32 AM
lib/xray/xray_interface.cc
217 ↗(On Diff #87590)

In x86-64 the acquire is in the assembly (spelled movq) because of the stronger memory model. That would change in weaker memory models, and since this is in a cross-platform part of the code, we have to be a bit more careful about this.

dberris accepted this revision.Mar 3 2017, 12:38 AM

LGTM

lib/xray/xray_fdr_logging.cc
497 ↗(On Diff #90435)

Potentially provide a comment to suggest that we ought to support this explicitly later (something like // FIXME: Handle actual argument logging later).

This revision is now accepted and ready to land.Mar 3 2017, 12:38 AM

I think this should land ASAP so we can get some testing. Things can be polished later.

lib/xray/xray_interface.cc
217 ↗(On Diff #87590)

Why do we care which order do the store and load happen? I can't think of a scenario where I'm enabling arg1 logging on one CPU and worrying about what happens on other CPUs at the same time with respect to me just enabling it. How is eventual consistency not enough?

Similarly, due to the strong memory model, you can look at the MOV as a relaxed operation that just got unnecessarily expensive because of Intel ;-)

dberris added inline comments.Mar 5 2017, 6:52 PM
lib/xray/xray_interface.cc
217 ↗(On Diff #87590)

Because on non-x86_64, these operations will really be relaxed. And because this isn't x86-specific code, we need to be careful about it.

For instance, the load in arm and ppc will need to be stronger versions (as it already is) to avoid having to deal with the issue of some threads not seeing the pointer update for potentially longer than when logging is on -- or they can stay relaxed but the write has to be strong so the appropriate caches are invalidated. A relaxed store here will mean that there's no strong guarantee that the data will show up as soon as the logging handler is installed, and threads can keep executing without seeing the handlers updated even if the sleds have been patched appropriately. We don't want this to happen because it affects data quality.

Does that make more sense?

pelikan updated this revision to Diff 90643.Mar 5 2017, 9:14 PM
  • strenghten and clarify how we treat the set_handler() operation w.r.t. the memory model
pelikan marked an inline comment as done.Mar 5 2017, 9:32 PM
pelikan added inline comments.
lib/xray/xray_interface.cc
217 ↗(On Diff #87590)

None of this answers the question "why do we care". The test behaviour depending on this, however, does. I've added a comment about why maintaining this is important.

pelikan updated this revision to Diff 90645.Mar 5 2017, 9:32 PM
pelikan marked an inline comment as done.
  • unify the API and clarify comments
pelikan updated this revision to Diff 90646.Mar 5 2017, 9:35 PM
  • remove handler needs to return and int too, for consistency

LGTM -- will land soon enough. Thanks @pelikan!

This revision was automatically updated to reflect the committed changes.