[lldb-dev] Seeking guidance on fixing an IOHandlerEditLine Hide/Refresh problem
Randy Smith
rdsmith at chromium.org
Fri Jul 11 12:33:16 PDT 2014
[Caveat: This is a minor issue, but it's annoying to me, so I'd like to at
least explore how to fix it properly before giving up.]
So my standard use of lldb is inside of gud-mode in emacs. In that mode, I
believe line editing is disabled (the output of lldb is a dumb terminal
that emacs wraps). As a result, IOHandlerEditLine::Hide and Refresh are
not balanced; Hide() does nothing, and Refresh() re-prints the prompt.
The result of this is that when I'm debugging an inferior that has a lot of
output, I get many copies of the (lldb) prompt interwoven with the output.
I've traced this behavior to Debugger::HandleProcessEvent() being called
repeatedly with event_type Process::eBroadcastBitSTDOUT. In such a
situation, it calls HideTopIOHandler(), copies the output out, and then
calls RefreshTopIOHandler().
The behavior that I personally think would be ideal in this configuration
would be for the prompt only to be refreshed if an inferior event *other*
than stdout or stderr occurs. And I can code that in
Debugger::HandleProcessEvent() pretty easily by only calling refresh if
some other event is occurs, but that's clearly the wrong architectural
choice (because it breaks the Hide/Refresh contract on IOHandler). Maybe
adding an argument to RefreshTopIOHandler indicating if the refresh was
requested because anything other than output was copied? I'm almost
tempted to just pass in the event type, but it doesn't really make sense
that IOHandlers know about the Process broadcast constants.
Anyone have any thoughts? (Including "This is minor and fixing it would be
a hassle; live with it" :-})
-- Randy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20140711/ccab2d9c/attachment.html>
More information about the lldb-dev
mailing list