labath wrote: > this does not catch > > https://github.com/llvm/llvm-project/blob/d775b911c90e631f5cc332c07474f7121564e25b/lldb/tools/lldb-dap/DAP.cpp#L215-L219 > > for example if you add the initcommand of `breakpoint set --file=main.c > --line=2 --command "bogus"` it is not sent to the important category
I don't think we want to redirect all of stderr here -- it's too easy to write something to it accidentally (e.g. a forgotten debug print in a python data formatter). I can imagine emitting a debugger diagnostic in cases like this, though I think that's a job for a different patch. > Maybe we limit it to only Errors. as on linux if lldb is not built with lzma > support it will spam warning messages like. > > ``` > warning: 45F7FBFE-9455-A458-4A50-347C4A5BC883/libsync.so No LZMA support > found for reading .gnu_debugdata section > warning: 8E2F4272-9D82-2CEF-A46D-C69DF3FEC722/liblog.so No LZMA support found > for reading .gnu_debugdata section > ``` Yeah, this is a good example of the bursty behavior. Limiting it only to errors might be a good idea, though I currentl feel like the distinction between errors and warnings is pretty arbitrary. Like, I don't see why this should be "only" a warning but the message in https://github.com/llvm/llvm-project/pull/132395 an error. However, this would at least give us an easy way to silence the most egregious offenders. I also think this LZMA message is important enough to see -- but once, not once for each module. So I can imagine a setup where the first of these messages would cause a popup and the rest would be squirrelled away somewhere -- but for that we'd need a better mechanism to track these. https://github.com/llvm/llvm-project/pull/137280 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
