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
|