Re: [remote protocol] Allow qSymbol response to continue packets

Daniel Jacobowitz
2004-03-11T23:38:35Z

On Thu, Mar 11, 2004 at 06:20:21PM -0500, Andrew Cagney wrote:
> Protocol's can't make such assumptions.

I disagree. I consider symbol lookup a _fundamentally non-blocking_
operation, and I'm sure there are other similar fundamentally
uninterruptible responses. For instance, any notification events (for
things similar to tracepoints, though I don't know if it would apply to
our tracepoint implementation, since the remote protocol bits of
tracepoint support do not have documentation that I can find). Or a
revised version of the 'console output' response that doesn't have the
protocol-breaking problems you described to me the last time I tried to
model something after it.

> >I don't think we need to use the heavy-weight mechanism which supports
> >interruption for operations that don't need to be interrupted, and I
> >can't see a reason to support interruption of this lookup. If you do,
> >please enlighten me.
>
> I think we'll have to disagree on our definitions of heavy weight (if F
> it is too heavy weight then perhaphs we need to remove a few things from
> it).
>
> The protocol needs to specify the failure states, the F packet provides
> that for free. As I said, I'm really not interested in cooking up
> another callback packet with a different set of failure states. One is
> enough.
>
> >>>You need to handle such race conditions anyway.
> >>>
> >>>-> c
> >>><- qSymbol | cntrl-c ->
> >
> >
> >That's a different problem, and it is already correctly handled by
> >gdbserver. We'll write out the qSymbol, read in the Ctrl-C, signal the
> >inferior, look again for an ACK, eventually get the ACK. Then we'd
> >wait for and get a qSymbol reply, resume the suspended thread that made
> >the lookup request, wait for it, and see the SIGINT we created.
>
> If you've code to handle that you've code to handle a packet containing:
>
> - <retry><cntrl-C>
> - <symbol><cntrl-C>

That's not correct, unfortunately. A packet containing
<symbol><cntrl-C>, sure, that's easy. But <retry><cntrl-C> is pretty
hard. The call stack at this point goes through the middle of
libthread_db; I can't resume the inferior to give it a real SIGINT
without have to jump through hoops to re-initialize libthread_db after
processing the SIGINT, so I would have to:

- stop all other running threads, if there are any; there could be
depending on what libthread_db is trying to look up
- forge a stop-with-SIGINT packet
- handle whatever packets GDB sends me while I'm stopped
- wait for GDB to resume
- cause the resume to trigger re-issue of the queued qSymbol "stop
response"
- repeat until this succeeds
- return that result to libthread_db

The long and short of it is that I'd have to duplicate or considerably
modularize the packet processing, to make the main loop re-entrant, to
support interruption of an otherwise non-blocking operation.