> If Modeled State is the state that is actually modeled by an actual > analysis tool, then perhaps Traced State is the complete state that it > is possible to model using the information stored in a trace.
Good point. Of course tracepoints are not always designed to directly trace a specific portion of state and may even expose only partially changes to some portion of the state. > The size of the Modeled state is an issue, since other than the actual > state of the system it is maintained and stored over time, sometimes > in a memory buffer on the target system. When would you store the modeled state on the target, this would not be typical to run the analysis tools live on the target itself? > A user making a very long > trace may want to store a more compact Modeled State than one looking > at a specific point in time. User filters could influence the Modeled > State, you could use triggers to automatically filter away parts of > the trace etc. While the trace can indeed get very long, the "current" "modeled state" normally does not grow with the trace size, rather with the modeled system size. The "modeled state" "history" would grow with the trace size, you may want to store it in order to allow quick seeking in the trace with full access to the "current" "modeled state" at the seek position. > Some user-space analyses could be more or less standard, such as > modeling the heap using traces of calls to malloc(), calloc(), > realloc() and free(). Other user-space analyses are probably custom. > Here the extensibility of the format will be put more to the test than > in kernel-space tracing. Good suggestion, allocation tracing is an example we should use as many are familiar with it. Very useful memory allocation debugging tools use modeled state extensively. Such tools store the addresses of all allocated objects and their current status. Furthermore, this "modeled state" can be used to find problems in cases where the application state is corrupted, which happens when you have memory allocation problems. _______________________________________________ linuxtools-dev mailing list linuxtools-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/linuxtools-dev
