Page MenuHomePhabricator

[trace][RFC] create skeleton for thread decoder

Authored by wallace on Aug 31 2020, 4:43 PM.



Depends on D86670.

I first just want to get feedback about the structures of the class in this patch, later I con polish it.

This adds the skeleton for decoding traces of threads. The first step is having the plug-in implementation decode its trace into raw instructions. Individual instructions can sometimes fail to be decoded, so the instruction class should have an is_error flag. Error are quite sporadic though.
I'm adding a TraceThread class that contains all the information needed to decode a trace. I'm creating another class TraceDecodedThread will is obtained by calling TraceThread::Decode and its existance indicates that decoding didn't fail and you can use that class for inspecting the decoding trace.
This means that TraceThread is like an initialization object, and then the analysis is done by the TraceDecodedTrace class, which splits responsibilities and makes error handling easier.

I added some comments in Trace.h as well.

Diff Detail

Event Timeline

wallace created this revision.Aug 31 2020, 4:43 PM
Herald added a project: Restricted Project. · View Herald TranscriptAug 31 2020, 4:43 PM
wallace requested review of this revision.Aug 31 2020, 4:43 PM

I am not sure we need any of the classes in Trace.h: TraceInstruction, TraceDecodedThread, or TraceThread.

We should be able to use history thread objects for threads that are currently vended by TraceThread. Each thread will have a current set of hard coded stack frames, which is what history threads already contain.

The only reason to put anything in the Trace.h file is for things that the plug-in will vend and we don't need any abstractions exposed at the plug-in level (TraceInstruction, TraceDecodedThread). Those can be abstracted inside of each Trace plug-in and no one will need to make their trace data fit into a specific mold (TraceInstruction, TraceDecodedThread).

The way I think about it trace plug-ins should be able to:

  • load from JSON + files on disk
  • dump all trace data
  • step/continue backward/forward and produce history threads at any time we stop and be able to show backtraces for any and all history threads for the current stop point

So none of this requires any changes to Trace.h IMHO, but I am open to opinions, that is just my initial train of thought.

wallace abandoned this revision.Sep 8 2020, 4:51 PM