Re: [PATCH] Don't pretend infcalls don't set the inferior running (PR gdb/34082)

[Pedro Alves <pedro@palves.net>]

On 2026-04-24 09:49, Andrew Burgess wrote:
> 
> Pedro,
> 
> Thanks for fixing this.  No real problems, one trivial nit, and a
> question, see below...
> 
> 
> Pedro Alves <pedro@palves.net> writes:
>> I think the right fix is to stop pretending that infcalls don't set
>> the target running.  I can't think of a reason we do that.  It really
>> does run.  Some thoughts:
>>
>> - I added to code to skip set_running (nowadays 'set_state(...,
> 
> typo: "I added to code" -> "I added THE code" ?

Yes, thanks, fixed.

> 
>>   THREAD_RUNNING))' for infcalls back in commit 4d9d9d0423 over 10
>>   years ago, but I honestly don't recall why.  My guess is that it
>>   must have been to keep backwards compatibility with something, and
>>   the code has probably changed sufficiently since then making it no
>>   longer necessary.
>>
>> - infcalls are always synchronous, so the intermediate running state
>>   can't be observed with commands.
> 
> I assume you mean by this that infcalls are something the user initiates
> from the prompt, and so while the infcall is running the user cannot
> also ask to inspect the thread state.
> 
> I don't disagree with any of your conclusions, but, if an infcall is
> made as part of a breakpoint condition, then than could run in the
> background, asynchronously, while the user is also issuing other
> commands.

No, it really can't.  Try something like this:

~~~~~~~~~~~~~~~~~~~~~~~~
#include <unistd.h>

static int
foo (void)
{
  usleep (1);
  return 0;
}

int
return_false ()
{
  sleep (10);     // <===  each condition eval will do an infcall that takes 10s.
  return 0;
}

int
main (int argc, char **argv)
{
  while (1)
    foo ();
  return 0;
}
~~~~~~~~~~~~~~~~~~~~~~~~


$ gdb -q ./a.bout -ex "start"
...
Temporary breakpoint 1, main (argc=1, argv=0x7fffffffd888) at test.c:64
64          foo ();
(gdb) b foo if return_false ()
Breakpoint 2 at 0x5555555551b1: file test.c, line 26.
(gdb) c&
Continuing.
(gdb) info threads
* hangs for up to 10 seconds here *
info threads
  Id   Target Id                                             Frame 
* 1    Thread 0x7ffff7f8f740 (LWP 1821559) "hand-call-new-t" (running)
(gdb) 
  Id   Target Id                                             Frame 
* 1    Thread 0x7ffff7f8f740 (LWP 1821559) "hand-call-new-t" (running)
(gdb) p 1
* hangs for up to 10 seconds here *
p 1
$1 = 1
(gdb) 

You have to try it to get a feel, but what happens is that GDB does not react
to commands while the infcall is ongoing, leading to those up to 10 seconds "hangs".

See here, in infcall.c:run_inferior_call:


      /* Infcalls run synchronously, in the foreground.  */
      scoped_restore restore_prompt_state
	= make_scoped_restore (&current_ui->prompt_state, PROMPT_BLOCKED);

      ...
      proceed ();
      ...

      /* Inferior function calls are always synchronous, even if the
	 target supports asynchronous execution.  */
      wait_sync_command_done ();


There's an old 
"SNIP - SNIP - SNIP - SNIP - SNIP - SNIP - SNIP - SNIP - SNIP"
line in infcall.c that suggests where we'd split the infcall machinery into a state machine.


But I think it'd be way more complicated than that hint suggests, infcalls happen in
the middle of expression evaluation, and the state for the expression is all on the stack.
We can't go back to the top event loop in the middle of an expression.  Not to mention 
we evaluate expressions all over the place, in the most innocuous-looking commands.
Any parse_and_eval with user input is potentially an infcall.


Also, if it were possible to issue command while a breakpoint condition is in the middle
of an infcall, the thread should still be considered THREAD_RUNNING up until the condition
evals false, meaning it really causes a user-visible stop.  So in that scenario, while
running the infcall, the thread would have been THREAD_RUNNING all the while, meaning,
there would be nothing new the user would be able to observe with this change.

> 
> Not that this changes anything.  In this situation the user believes
> that the inferior is running in the background, so seeing the threads as
> running is absolutely fine.  I'm just not convinced that the claims made
> in this point "infcalls are always asynchronously" and "the intermediate
> running state can' be observed" are correct.
> 
> But the patch itself makes a lot of sense, and looks good.
> 
> Approved-By: Andrew Burgess <aburgess@redhat.com>

Thanks.

Pedro Alves

> 
> Thanks,
> Andrew
>