Thank you for writing this Walter. I think this document will be a useful reference both now and in the future.
The part that's not clear to me is what is the story with multi-process traces. The file format enables those, but it's not clear how are they going be created or used. Can you elaborate more on what you intend to use those for? The main reason I am asking that is because I am thinking about the proposed command structure. I'm wondering if it would not be better to fit this into the existing target/process/thread commands instead of adding a new top-level command. For example, one could imagine the following set of commands: - "process trace start" + "thread trace start" instead of "thread trace [tid]". That would be similar to "process continue" + "thread continue". - "thread trace dump [tid]" instead of "trace dump [-t tid]". That would be similar to "thread continue" and other thread control commands. - "target create --trace" instead of "trace load". (analogous to target create --core). - "process trace save" instead of "trace save" -- (mostly) analogous to "process save-core" I am thinking this composition may fit in better into the existing lldb command landscape, though I also see the appeal in grouping everything trace-related under a single top-level command. What do you think? The main place where this idea breaks down is the multi-process traces. While we could certainly make "target create --trace" create multiple targets, that would be fairly unusual. OTOH, the whole concept of having multiple targets share something is a pretty unusual thing for lldb. That's why I'd like to hear more about where you want to go with this idea. On 21/09/2020 22:17, Walter via lldb-dev wrote: > Thanks for your feedback Fangrui, I've just been checking Capn' Proto > and it looks really good. I'll keep it in mind in the design and see how > it can optimize the overall data transfer. I'm not sure how Cap'n Proto comes into play here. The way I understand it, the real data is contained in a separate file in the specialized intel format and the json is just for the metadata. I'd expect the metadata file to be small even for enormous traces, so I'm not sure what's to be gained by optimizing it. pl _______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
