I had accepted the patch https://reviews.llvm.org/D86670 <https://reviews.llvm.org/D86670>, but then marked as "Request Changes" while we discuss the commands in this RFC after new comments came in.
> On Oct 1, 2020, at 1:42 PM, Greg Clayton <clayb...@gmail.com> wrote: > > 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 >> <mailto: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
