wallace added inline comments.
================ Comment at: lldb/docs/lldb-gdb-remote.txt:369 +// +// /* process tracing only */ // "processBufferSizeLimit": <decimal integer>, ---------------- jj10306 wrote: > Why do we only want this option for process tracing? > Per cpu tracing collects all trace data agnostic to a user specified > process/thread, so why should this only be exposed for process wide? I think > it makes more sense to decouple the `perCoreTracing` option from > process/threads specific options entirely so it is its own option all > together and cannot be used in conjunction with process/thread options. > If there is reason to not go down that route, we then should also add support > for `perCoreTracing` with the thread tracing option, not just the process > tracing option as I feel it doesn't make since to only expose this for > process tracing since it's doing the same thing behind the scenes. The reason is that if you want to trace a specific thread, it's actually much better to use single-buffer thread tracing than per cpu. You get full fidelity and no data loss in this mode. On the other hand, per cpu tracing is really useful in a thread-unbounded case where you are okay with having no data for unfrequent threads. Per-core single-tracing is doable, but it's very impractical in the context of LLDB. However, if we ever need to implement it eventually, we for sure can refactor the code for that. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D124640/new/ https://reviews.llvm.org/D124640 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
