We spoke a bit after Panel's comments which made sense and we propose the commands Walter sent below. Let us know what everyone thinks of this organization of the command structure!
> On Oct 1, 2020, at 1:32 PM, Walter <a20012...@gmail.com> wrote: > > After a chat with Greg, we agreed on this set of commands > > > trace load /path/to/json > > process trace start/stop > process trace save /path/to/json > > thread trace start/stop > thread trace dump [instructions | functions] > > > Il giorno gio 1 ott 2020 alle ore 13:21 Greg Clayton <clayb...@gmail.com > <mailto:clayb...@gmail.com>> ha scritto: > > > > On Oct 1, 2020, at 7:08 AM, Pavel Labath via lldb-dev > > <lldb-dev@lists.llvm.org <mailto:lldb-dev@lists.llvm.org>> wrote: > > > > 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? > > Mainly for system trace kinds of things where an entire system gets traced. > > > > > 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. > > I kind of see tracing has having two sides: > 1 - post mortem tracing for individual or multiple processes > 2 - live debug session tracing for being able to see how you crashed where > trace data is for current process only > > For post mortem tracing, the trace top level command seemed to make sense > here because there are no other target commands that act on more than one > target. So "trace load" makes sense to me here for loading one or more > traces. The idea is the trace JSON file has enough info to completely load up > the state of the trace so we can symbolicate, dump and step around in > history. So I would vote to keep "trace load" at the very least because it > can create one or more targets. Options can be added to display the processes > if needed: > > (lldb) trace list <trace-json-file> > > But we could move "trace dump" over into "target trace dump" or "process > trace dump" since that is effectively how we are coding these patches. > > For live debugging where we gather trace data through the process plug-in, we > will have a live process that may or may not have trace data. If tracing > isn't available we will not be able to dump anything. But I would like to see > process/thread commands for this scenario: > > - process trace start/stop (only succeeds if we can gather trace data through > the process plug-in) > - thread trace start/stop (which can succeed only if current tracing can > enable tracing for only one thread) > > Not sure if we need "process trace save" or "thread trace save" as the saving > can be done as an option to "process trace stop --save /path/to/save" > > So I am all for fitting these commands in where they need to go. > > > > > 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 <mailto:lldb-dev@lists.llvm.org> > > https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > > <https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev> > > > > -- > - Walter ErquÃnigo Pezo >
_______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
