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

[Andrew Burgess <aburgess@redhat.com>]

Pedro Alves <pedro@palves.net> writes:

> 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.

Thanks for taking the time to explain this.  That all makes sense.

Thanks,
Andrew


>
>> 
>> 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
>>