[Lldb-commits] [lldb] [lldb-dap] Updating the logging of lldb-dap to use existing LLDBLog. (PR #129294)

[Adrian Vogelsgesang via lldb-commits]

================
@@ -0,0 +1,30 @@
+//===-- DAPLog.cpp --------------------------------------------------------===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===----------------------------------------------------------------------===//
+
+#include "DAPLog.h"
+
+using namespace lldb_private;
+using namespace lldb_dap;
+
+static constexpr Log::Category g_categories[] = {
+    {{"transport"}, {"log DAP transport"}, DAPLog::Transport},
+    {{"protocol"}, {"log protocol handling"}, DAPLog::Protocol},
+    {{"connection"}, {"log connection handling"}, DAPLog::Connection},
+};
+
+static Log::Channel g_log_channel(g_categories, DAPLog::Transport |
+                                                    DAPLog::Protocol |
+                                                    DAPLog::Connection);
+
+template <> Log::Channel &lldb_private::LogChannelFor<DAPLog>() {
+  return g_log_channel;
+}
+
+void lldb_dap::InitializeDAPChannel() {
+  Log::Register("lldb-dap", g_log_channel);
----------------
vogelsgesang wrote:

does this mean, I could now write `log enable lldb-dap connection` from the lldb-dap console, and get the log messages directly printed to my VS-Code debug console? That would be pretty neat 🎉 

But... What would happen if I run `log enable lldb-dap protocol`? Afaict, this would lead to an endless cycle of:

1. lldb-dap receives a `stackTrace` command
2. as part of receiving this `stackTrace` command, we will be writing to the `Protocol` log (see `DAP::ReadJSON()`)
3. because logging for this channel is enabled, we try to send the log message to the debug client via an `output` event
4. but this attempt to send the log-information goes through `DAP::sendJSON` which will also writing to the `Protocol` log
5. which in turn will trigger another `output` event
6. which will again go through `DAP::sendJSON`
7. which in turn will trigger another `output` event
8. which will again go through `DAP::sendJSON`
9. and so on...

Is this something we can / should guard against?

https://github.com/llvm/llvm-project/pull/129294