Re: -exec-step over a blocking function call

[Vladimir Prus <vladimir at codesourcery dot com>]

Aleksandar Ristovski wrote:

> Hello,
> 
> I have encountered a problem using MI interface. It is not very easy to
> reproduce, hence no real test case, but I will try to describe what I am
> seeing:
> 
> This is the situation I have:
> 
> (gdb)
> -exec-step 1
> ^running
> (gdb)
> ~"Single stepping until exit from function SyncSemWait, \n"
> ~"which has no line number information.\n"
> 
> 
> Where SyncSemWait is a blocking function (as the name suggests, waiting for
> semaphore). Gdb will just sit here since the inferior has several threads,
> one
> of which is reading stdin waiting for user input, and apparently input would
> 
> unblock. But until it does, gdb is sitting here. The problem I am seeing is
> that
> often, while waiting for SyncSemWait to return IDE would issue additional mi
> 
> commands which eventually make gdb crash or appear frozen (unresponsive).

So which is that -- crash or appear frozen?

In the majority of cases, GDB does not read or processes further 
MI commands while waiting for the target to stop 
(which it does in your case). And even if it accepts commands, 
there's just one allowed command -exec-interrupt.
If the IDE attempts to any other command, the IDE has a bug.

> 
> I am not sure how should gdb deal with this situation. Any ideas?

Please check the spec of MI changes for async targets that I've posted
yesterday. It would be great if the IDE developers also glance and make
omments before I implement it all.

- Volodya