On Wed, Aug 10, 2011 at 8:20 AM, Tom Tromey <tromey@redhat.com> wrote:
> Matt> So, I guess neither the current patch or adding the observer calls
> Matt> to the existing code is correct and we at least need to split up
> Matt> prompt displaying from the setting of the prompt parameter?
>
> I'm afraid I don't have an answer for you.

thats alright, updated patch, modifications from the previous patch include
on the code side we need to avoid calling the observer/prompt_hook
when sync_execution is enabled,
wrt tests check for double prompting in lib/prompt.exp, and add
sync_execution tests,
and tests for the prompt_hook function's argument.

if we don't check sync_execution when calling the prompt_hook:
in the sync_execution && is_running case this leads to prompt_hook
being called for a prompt that is never displayed (giving the
prompt_hook an empty string argument from async_disable_stdin).

in the sync_execution && !is_running case the fallthrough can lead to
a 'double prompt', if the prompt_hook overrides the empty prompt that
async_disable_stdin sets, then it prompts again in the future.

there is a concerted effort (see below for examples), that we force
the prompt to return early, avoiding readline stuff, and then
re-calling it in the future, when the signal handling won't get in the
way, the first prompt does not seem to be different in regard to this
than any other, thus the cli_command_loop call to display_gdb_prompt,
returns early, then later in fetch_inferior_event, we call it again
without sync_execution set, and its only then that we get the first
prompt and setup readline.

doing readline stuff in cli_command_loop (in the case of
sync_execution) was causing 10720.
because sync_execution is set during command handling which happens
before the first prompt.
and it wasn't testing that flag.

thus, I don't think returning early is a problem here, i believe it is
working as intended, though this entire mechanism does seem complex
and fragile... anyhow that is my understanding of it, thanks for your
patience.

infrun.c:fetch_inferior_event (~2815)
  /* If the inferior was in sync execution mode, and now isn't,
     restore the prompt.  */
  if (was_sync && !sync_execution)
    display_gdb_prompt (0);

inf-loop.c:inferior_event_handler (~58)
          async_enable_stdin ();
          display_gdb_prompt (0);

inf-loop.c:inferior_event_handler (~73)
      /* The call to async_enable_stdin below resets 'sync_execution'.
         However, if sync_execution is 1 now, we also need to show the
         prompt below, so save the current value.  */
      was_sync = sync_execution;
      async_enable_stdin ();

P.S. I have seen some core dumps on exit in the sync_execution
versions of these tests, both with and without the patch.
along with random stopping after 'continue&', i'm not very familiar
with target-async so i'm not exactly sure what to make of it.

no new failures (not even a spurious one, weird), all new tests pass.

2011-08-11  Matt Rice  <ratmice@gmail.com>

        * event-top.c (cli_command_loop): Replace readline setup with
        direct call to display_gdb_prompt.
        (display_gdb_prompt): Do not call observer mechanism during
        synchronous execution.

2011-08-11  Matt Rice  <ratmice@gmail.com>

        * lib/prompt.exp: New file for testing the first prompt.
        * gdb.python/py-prompt.exp: Ditto.
        * gdb.python/py-prompt.c: Ditto (copy of ext-attach.c).