The event should get delivered to the Debugger thread that is waiting for
events and it should coordinate with the top io handler when printing it. If
someone is grabbing the event manually by hijacking events, then we need to fix
that code to send the event on to the unhijacked main event loop.
> On Aug 20, 2014, at 1:42 AM, Matthew Gardiner <m...@csr.com> wrote:
>
> Hi folks
>
> I have been seeing another issue with the display of the lldb prompt. This
> time it's when I do "target create elf-file", then "gdb-remote port-number".
> After the "gdb-remote" command I see the fact that my process is stopped, e.g.
>
> Process 1 stopped
>
> on the screen. But no (lldb) prompt.
>
> Some investigation revealed that what's *probably* happening is the main
> thread after processing the "gdb-remote" returns to it's IOHandler, which
> then prints (lldb). However, the inferior's state changes seem to delivered
> to stdout via a different thread, basically one which sits in
> Debugger::DefaultEventHandler. This subsequent output then, I think,
> overwrites the previous (lldb) prompt.
>
> Now in my (and presumably other people's) situation, this issue is compounded
> by the speed of the TCP/IP connection to the gdbserver stub, the "poll the
> hardware" nature of my stub, and the fact the hardware is actually simulated
> - yes over a TCP/IP socket.
>
> FWIW, I resolved this by a horrible (POSIX only) hack, of sleeping for 300ms
> at the bottom of the CommandInterpreter::HandleCommand function.
>
> @@ -9,6 +9,8 @@
>
> #include "lldb/lldb-python.h"
>
> +#include <poll.h> // MG for prompt bugs
> +
> #include <string>
> #include <vector>
> #include <stdlib.h>
> @@ -1916,6 +1918,9 @@
> if (log)
> log->Printf ("HandleCommand, command %s", (result.Succeeded() ?
> "succeeded" : "did not succeed"));
>
> + // MG wait for remote connects etc. to complete
> + poll(0,0,300);
> +
> return result.Succeeded();
> }
>
>
> But this is horrid. Given this, and other prompt issues, I'm wondering
> whether whether we need some brave soul, to redesign the current lldb IO
> handling mechanisms.
>
> Matt
>
>
>
>
>
>
>
> Member of the CSR plc group of companies. CSR plc registered in England and
> Wales, registered number 4187346, registered office Churchill House,
> Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
> More information can be found at www.csr.com. Keep up to date with CSR on our
> technical blog, www.csr.com/blog, CSR people blog, www.csr.com/people,
> YouTube, www.youtube.com/user/CSRplc, Facebook,
> www.facebook.com/pages/CSR/191038434253534, or follow us on Twitter at
> www.twitter.com/CSR_plc.
> New for 2014, you can now access the wide range of products powered by aptX
> at www.aptx.com.
> _______________________________________________
> 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
