Page MenuHomePhabricator

Please use GitHub pull requests for new patches. Phabricator shutdown timeline

[WIP][lldb][windows] Handle OutputDebugString from debuggee
Needs ReviewPublic

Authored by alvinhochun on Jun 24 2022, 10:21 AM.

Details

Summary

This implements handling of OUTPUT_DEBUG_STRING_EVENT which prints the
debug strings using LLDB_LOG (channel "windows", category "dbgprint").

  • TODO: see if there is a better way to output the debug strings...

Diff Detail

Event Timeline

alvinhochun created this revision.Jun 24 2022, 10:21 AM
Herald added a project: Restricted Project. · View Herald TranscriptJun 24 2022, 10:21 AM

WIP. To test this, first compile a test program (not needed if you already have programs that does OutputDebugString):

#include <windows.h>

int main() {
    OutputDebugStringW(L"Hello debug string");
    return 0;
}

Debug the program in lldb. Before running the program, you need to run the command log enable windows dbgprint. When you run the program, you should see "DEBUG: Hello debug string" output in lldb.

I think this should be enabled by default, but none of the logging categories for LLDB_LOG has default active. Is there a better way to do this? The log output can also get mixed with command output.

Add size check

For context - does gdb handle this too, and is it printed out to the gdb console?

Did you test this both with and without lldb-server? (See ShouldUseLLDBServer in ProcessWindows.cpp.)

For context - does gdb handle this too, and is it printed out to the gdb console?

Yes, gdb prints them to the console with a warning: prefix.

Did you test this both with and without lldb-server? (See ShouldUseLLDBServer in ProcessWindows.cpp.)

It works without lldb-server. I tested lldb-server just now and found that none of the log output is printed -- I tried enabling all windows logging categories but got nothing. (I rebased the change onto 0aa6df65756d3ec7769e55424a41c7074849fe12 before testing.)

alvinhochun edited the summary of this revision. (Show Details)

Added test for Windows

alvinhochun published this revision for review.Jun 29 2022, 8:46 AM
Herald added a project: Restricted Project. · View Herald TranscriptJun 29 2022, 8:46 AM

I think this should be enabled by default, but none of the logging categories for LLDB_LOG has default active.

That's because it's not really meant for this use case. The logging infrastructure is for internal lldb logs, not for application output. Reusing it for this purpose is an interesting idea, and it might even make sense, depending on what do people use ODS for (and I really don't know the answer to that), but it is definitely unorthodox.

It also has the problem of only working for in-process debugging (which we'd like to get rid of), as logs don't get sent over the gdb-remote connection (unless you take steps to send them over and *then* log them).

Is there a better way to do this?

Well.. most OSes don't have this kind of functionality, so we don't really have an exact match for this. I suppose the closest thing would be the way we handle darwin OS logs, so you could try to see if reusing some of that infrastructure makes sense (StructuredDataDarwinLog.cpp and surrounding code).

One cheap way to accomplish this would be to pass this off as program standard output (possibly prefixed by ODS: or something). Then it would show up on the lldb console, could be accessed by SBProcess::GetSTDOUT, and everything. It might not even be /too/ confusing, as we currently don't proxy stdout this way (though that's also something that I'd like to see changed).

lldb/source/Plugins/Process/Windows/Common/ProcessWindows.cpp
826–827

How exactly does it interfere? Have you tried a consume_back(StringRef("\0", 1)) ?

Well.. most OSes don't have this kind of functionality, so we don't really have an exact match for this. I suppose the closest thing would be the way we handle darwin OS logs, so you could try to see if reusing some of that infrastructure makes sense (StructuredDataDarwinLog.cpp and surrounding code).

Thanks, StructuredData looks interesting and it seems like a nice way to do this (albeit looking to be slightly overcomplicated). But I did a bit of digging and found D106324, and I get the impression that it was planned to be removed eventually. Is it still a good idea to reference that?

One cheap way to accomplish this would be to pass this off as program standard output (possibly prefixed by ODS: or something). Then it would show up on the lldb console, could be accessed by SBProcess::GetSTDOUT, and everything. It might not even be /too/ confusing, as we currently don't proxy stdout this way (though that's also something that I'd like to see changed).

This can work, but certainly not ideal.

Well.. most OSes don't have this kind of functionality, so we don't really have an exact match for this. I suppose the closest thing would be the way we handle darwin OS logs, so you could try to see if reusing some of that infrastructure makes sense (StructuredDataDarwinLog.cpp and surrounding code).

Thanks, StructuredData looks interesting and it seems like a nice way to do this (albeit looking to be slightly overcomplicated). But I did a bit of digging and found D106324, and I get the impression that it was planned to be removed eventually. Is it still a good idea to reference that?

Hmm... good question. I don't know. Maybe @jasonmolenda can say something about that.

I, for one, would be definitely happy to see that entire subsystem go up in smoke, but if there is a use for it, I suppose we can keep it. The fact that there is no current user of it means that you may be able to redesign/replace the system with something more suitable to your use case.