[Lldb-commits] [lldb] [lldb] Synchronize the debugger's stdout and stderr streams (PR #126630)

Pavel Labath via lldb-commits lldb-commits at lists.llvm.org
Mon Feb 17 09:15:45 PST 2025


labath wrote:

> > > A random idea, I don't know if it's a good one: have one object (LockableStreamPair?) that holds the two streams and their mutex. One less argument to pass around?
> > 
> > 
> > Sounds good, that simplifies the signatures (which this PR is already touching) and keeps the mutex abstracted away.
> 
> I did implement this and I'm not happy with the result: even though you only pass one object, you still need to get the output or error stream out of it which ends up being more verbose. And because of the `IOHandler` and `Debugger::AdoptTopIOHandlerFilesIfInvalid` it needs to be a shared pointer. Here's what that looks like: [d62fdae](https://github.com/llvm/llvm-project/commit/d62fdaec4cd322574e1ab78c8cacd1effe2c29c0). It compiles but some tests are failing. Probably something small but given I don't like the approach I haven't looked into it.

That's okay. I thought it might not work out. Thanks for giving it a shot.

I feel bad about bringing this up after you did all the work, but there is one more thing going through my head. I now have a very awkward feeling about this because it seems like this is solving mostly the same problem that StreamAsynchronousIO (and Debugger::PrintAsync) was trying to solve. You mentioned that in the first version of the patch and said that it doesn't work in some cases, but it's not quite clear why is that the case. If the motivation is status line, then it sounds like it *might* be possible to plumb the updates through the async streams.

I can imagine that it might not work for some reason, but then I think it's important to know why, and come up with some sort of an story for which of the two systems should be used for a particular use case. Or, (I am dreaming, I know) actually deprecate/remove the async IO system.

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


More information about the lldb-commits mailing list