🍒 [windows][lldb] implement system logging on Windows (#150213) #11096
Conversation
charles-zablit
commented
Jul 31, 2025
- [windows][lldb] implement system logging on Windows llvm/llvm-project#150213
This patch makes LLDB use the Event Viewer on Windows (equivalent of system logging on Darwin) rather than piping to the standard output (which was deactivated in ca0a524.
|
@swift-ci please test |
|
@swift-ci please test windows |
|
@swift-ci please test |
|
@swift-ci please test Windows |
|
@swift-ci please test windows |
|
@swift-ci please test Windows |
| event_type = EVENTLOG_INFORMATION_TYPE; | ||
| } | ||
|
|
||
| ReportEventW(h, event_type, 0, 0, nullptr, 1, 0, &msg_ptr, nullptr); |
There was a problem hiding this comment.
Is this really the best place to put the messages? The Event Log is for system events, this feels more developer oriented and feels like the kernel debug buffer might be better (OutputDebugStringA).
There was a problem hiding this comment.
From my understanding, the messages outputted through OutputDebugStringA are only accessible from an attached debugger or something like DebugView (which still requires attaching). The goal of this PR is to mimic what lldb does on Darwin with system logging, which does not require a debugger.
this feels more developer oriented
I think the health logs are useful for users as well to understand if their install is broken. I would say that they are also useful for lldb users.
There was a problem hiding this comment.
Sure, but I don't think that the event viewer is the right location for the logging. This log tends to be very very very very verbose. If this only was triggered in the case that lldb is dying, that would be one thing. But this is effectively triggered on each run of lldb.
There was a problem hiding this comment.
This log tends to be very very very very verbose.
Are you talking about the overall system events or just the lldb health logs? I agree that the overall system logs (the contents of the event viewer) has a lot of entries. However the UI and the search bar allow to filter them easily. The Console on macOS also has a lot of entries and we can filter messages fine. I assume it's the same on Linux.
My reasoning for using the event viewer is:
- Even though there are a lot of entries, the UI allows to quickly find
lldbrelated entries. - This is the closest match to how we log on other platforms. We could switch to using
OutputDebugStringAhowever we should also do so on other platforms. I don't think it's a good UX for users to need to use a debugger on Windows to get the health logs, but to only have to open the Console to get them on macOS.
I would be in favor of taking this change in 6.2 and to propose a migration to another destination for health logs on all platforms on the forums further down the line. What do you think?
There was a problem hiding this comment.
I am referring to the lldb side. I don't think that Linux is the same. syslog is just a flat file though these days you would find the logs somewhere in systemd I imagine which isn't really easy to filter.
This is too late for 6.2 IMO. So we are better off just changing this now before merging.
| std::wstring unicode(unicode_length, L'\0'); | ||
| MultiByteToWideChar(CP_ACP, 0, ansi.c_str(), -1, &unicode[0], unicode_length); | ||
| return unicode; | ||
| } |
There was a problem hiding this comment.
Why re-implement UTF8ToUTF16 and UTF16ToUTF8 from LLVM?
There was a problem hiding this comment.
Opened a PR upstream to address this. Thanks!