One option would be to redirect stdin/out/err when you launch your process:
(lldb) process launch --stdin /path/to/stdin.txt --stdout /path/to/stdout.txt --stderr /path/to/stderr.txt Not sure if you could make a new emacs buffer that could hook up the in/out/err file handles to the inferior process? If you do that, then no eBroadcastBitSTDOUT will be sent! I don't know much about the emacs, but it seems like this might be nice to get all of your process input/output in a separate window? Greg > On Jul 11, 2014, at 12:33 PM, Randy Smith <rdsm...@chromium.org> wrote: > > > [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 > > > _______________________________________________ > lldb-dev mailing list > lldb-dev@cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev _______________________________________________ lldb-dev mailing list lldb-dev@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
