JDevlieghere added a comment. In D135621#3849043 <https://reviews.llvm.org/D135621#3849043>, @labath wrote:
> I'm not sure if this will do what you wanted it to do. Despite the title, > this patch is not adding a new log *channel* -- it is adding a new log > *category* to the "lldb" channel. Our logging infra, perhaps somewhat > misleadingly, manages all of the log state on a per-channel basis. This means > that it is not e.g. possible to redirect one log category to a different sink > than a different category in the same channel. I haven't checked this, but I > suspect that for this reason, any explicit "log enable" commands by the user > will redirect this special channel into the new (user-provided) destination. > If this is not what you intended to do then, you probably ought to add a new > log channel, for real. You're absolutely right. I actually came to that same conclusion myself when I implemented an earlier iteration of this patch a long while ago but evidently didn't think of it before recreating the patch from memory. > That said, without knowing what kind of information do you want to log here, > I am wondering if the same kind of information could be gathered by reusing > some existing data collection mechanism, like session transcripts, or the > yet-to-be-implemented telemetry data. I see those two things as orthogonal. Always-on logging is something that has comes up quite frequently. @kastiglione can talk about our downstream log channel for Swift and @Michael137 was also interested in this to triage common issues with the expression evaluator. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D135621/new/ https://reviews.llvm.org/D135621 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
