Register tracing export #178
Conversation
buffalojoec
left a comment
buffalojoec
left a comment
There was a problem hiding this comment.
I saw this is still in draft, so just a few fly-by things I noticed!
This is looking really good, though. Make sure to add some tests and a README section for the new feature!
|
@procdump I see why this is such a pain. We have to coordinate initial cache compilation as well as per-invocation tracing, all while giving users the ability to customize behavior. I threw a few commits up to see what you think. Basically I've implemented the following:
With those changes, we can lose the extra constructor and simplify a few things. Considering what I said in bullet 1, we actually could just remove it from |
buffalojoec
left a comment
buffalojoec
left a comment
There was a problem hiding this comment.
Lgtm, just some nits on the README to make it a bit more clear. Nice work!
Bury the logic in the callback structure - if there's a register tracing callback then have the functionality enabled. With the current with_register_tracing constructor it's now possible to switch on register tracing without playing with envvars. This is shown in the provided test in this commit. Tweaking the SBF_TRACE_DIR envvar, however, is useful for existing codebases where Mollusk users are willing to enable register tracing instantly without making any changes to their code.
1. fixes a comment to be above the statement it pertains to 2. removes with_register_tracing 3. changes the register_tracing test to use the enable_register_tracing variable for switching on/off instead of playing with the callback.
2. Reintroduces that upon instantiation if SBF_TRACE_DIR is set Mollusk will have register tracing enabled. This would allow users to actually get tracing data without changing their code by simply setting the environment variable. 3. Fixes a comment.
… tracing in the end.
procdump
force-pushed
the
register_tracing
branch
from
87e4631 to
94ece29
Compare
|
All suggestions fixed and rebased - have a look now. |
Oops - apparently that one was me. Thanks for fixing! |
2 participants
Problem
With solana-sbpf 0.13.1 it's possible to collect register tracing data in a consistent way. Yet a testing harness like mollusk does not provide a default mechanism to collect this data in a useful format for later ingestion.
The idea of this PR is to provide such mechanism in a way consumer tools could take advantage of - particularly willing to analyze the tracing data and generate statistics on top of it.
Solution
The PR takes advantage of the
invocation-inspect-callbackfeature where a callback could be called prior to or after the processed instruction. A default post instruction callback for storing the register tracing data in files is provided and it basically persists the register sets, sbpf instructions and an identification sha256 hash of the executable that was actually used for the generation of this data. The motivation behind providing the sha256 identification is that files could grow in number and it's necessary for the consumer to be able to distinguish which shared object to use when analyzing the tracing data in a deterministic way. Also in order to let consumers instantly take advantage of this feature it's written in a way that register tracing gets enabled as long as theSBF_TRACE_DIRis provided denoting the directory in which the tracing data will be persisted. The motivation behind this approach is that it will let users instantly get out the tracing data of their tests which can eventually be passed to statistics generators such as code coverage tools, disassemblers, etc.Review
Before getting further I'd be happy to get some feedback if you find this approach feasible or have a better idea how it may be done.