[lldb] Log to system log instead of stderr from Host::SystemLog

[JDevlieghere]

Currently, calls to Host::SystemLog print to stderr on all host platforms except Darwin. This severely limits its value on the command line, where we don't want to overload the user with log messages. Switch to using the syslog function on POSIX systems to send messages to the system logger instead of stdout.

On Darwin systems this sends the log message to os_log, which matches what we do today. Nevertheless I kept the current implementation that uses os_log directly as it gives us more freedom.

I'm not sure if there's an equivalent on Windows, so I kept the existing behavior of logging to stderr.

[llvmbot]

@llvm/pr-subscribers-lldb

Author: Jonas Devlieghere (JDevlieghere)

Changes

Currently, calls to Host::SystemLog print to stderr on all host platforms except Darwin. This severely limits its value on the command line, where we don't want to overload the user with log messages. Switch to using the syslog function on POSIX systems to send messages to the system logger instead of stdout.

On Darwin systems this sends the log message to os_log, which matches what we do today. Nevertheless I kept the current implementation that uses os_log directly as it gives us more freedom.

I'm not sure if there's an equivalent on Windows, so I kept the existing behavior of logging to stderr.

---

Full diff: https://github.com/llvm/llvm-project/pull/83366.diff

1 Files Affected:

• (modified) lldb/source/Host/common/Host.cpp (+9)

diff --git a/lldb/source/Host/common/Host.cpp b/lldb/source/Host/common/Host.cpp
index f4cec97f5af633..1af01ef5025bc4 100644
--- a/lldb/source/Host/common/Host.cpp
+++ b/lldb/source/Host/common/Host.cpp
@@ -89,8 +89,17 @@ using namespace lldb;
 using namespace lldb_private;
 
 #if !defined(__APPLE__)
+#if !defined(_WIN32)
+#include <syslog.h>
+void Host::SystemLog(llvm::StringRef message) {
+  openlog("lldb", LOG_CONS | LOG_PID | LOG_NDELAY, LOG_USER);
+  syslog(LOG_INFO, "%s", message.data());
+  closelog();
+}
+#else
 void Host::SystemLog(llvm::StringRef message) { llvm::errs() << message; }
 #endif
+#endif
 
 #if !defined(__APPLE__) && !defined(_WIN32)
 static thread_result_t

[rupprecht]

It's been a while since I really looked deep into the syslog APIs, which are a little archaic. And it's possible that calls to Host::SystemLog are rare enough that none of these things are concerning, even if they are valid concerns for high load use cases:

• I believe it's typical for openlog and closelog to only be called once. Opening and closing on every syslog call may be costly/unnecessary.
• But actually, both openlog and closelog are technically optional -- still a good idea to at least call openlog so you can pass ident and option (the facility you could just pass in the syslog call). For closelog, I wonder if you could just skip that, and hopefully the openlog() call on subsequent Host::SystemLog() calls would end up being noop'd/cached?
• IIRC, calls to syslog can block, e.g. if the daemon processing syslog entries gets backed up, then syslog will block until the queue becomes less full. Keeping syslog calls on a separate thread may be safer.

[rupprecht]

Also, cc @oontvoo who is looking at this stuff more closely now

[JDevlieghere]

Thanks Jordan. I've moved the openlog behind a call_once flag and omitted the closelog.

I considered executing syslog on the debugger's thread pool but the fact that Core depends on Host means that would be a layering violation and there's no good place to manage the futures something like std::async would return.

Right now the system log function is only used for the corresponding log handler which is purely opt-in. I do plan to use it in other places (e.g. the debugger diagnostics) but even then I expect it to be relatively low traffic.

[JDevlieghere]

@rupprecht @oontvoo How do you feel about the current approach? The other alternative is to make this function a NOOP on all platforms but Darwin (where I want to actively use it). It's not currently load bearing (except the log, which is opt-in).

[rupprecht]

@rupprecht @oontvoo How do you feel about the current approach? The other alternative is to make this function a NOOP on all platforms but Darwin (where I want to actively use it). It's not currently load bearing (except the log, which is opt-in).

This approach LGTM. Potentially we will want calls to syslog to be different or configurable somehow, but we can cross that bridge when we get to it.