[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