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

[Daniel Jacobowitz <drow at false dot org>]

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.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer