[Lldb-commits] [lldb] [lldb] Log to system log instead of stderr from Host::SystemLog (PR #83366)

Jordan Rupprecht via lldb-commits lldb-commits at lists.llvm.org
Wed Feb 28 20:04:56 PST 2024


================
@@ -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();
----------------
rupprecht wrote:

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.

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


More information about the lldb-commits mailing list