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

[Daniel Jacobowitz <drow at false dot org>]

On Thu, Mar 11, 2004 at 04:27:16PM -0500, Andrew Cagney wrote:
> 
> >>>look through the File-I/O section that discuss cntrl-c.
> >>>
> >>>I think something based on the existing F packet would be better.  At 
> >>>least that way we have a situtation where the clear intent is for 
> >>>identical semantics.
> >
> >
> >Could you explain why you this is necessary?
> 
> >I'm guessing in the File I/O case this handles the user hitting C-c
> >while the client is processing a request, and there is considerable
> >complexity involved in reporting whether the I/O has completed.  But
> >using errno doesn't make any sense in the symbol lookup context and it
> >seems to me easier to make GDB delay sending the C-c to the target
> >until the qSymbol has been processed:
> >  -> c
> >  <- qSymbol:AAAAAAAAAAAAA
> >  Control-C
> >  -> qSymbol:AAAAAAAAAAAAA:012131312
> >  -> \003
> 
> Here's the problem:

I did read the manual when you referenced it, you don't need to paste
the whole thing :)

> A user trying to cntrl-c GDB while GDB is taking its time looking up a 
> symbol isn't theory.  There needs to be an error/abort mechanism and 
> adopting "F" provides that.
> 
> The alternative is to specify some sort of customized q packet semantics 
> - giving two callbacks and two different behaviors  - I'm really not 
> interested in going there.

Perhaps you've noticed that we have hashed minimal symbol table
lookups?  There is no excuse for symbol table lookups to take long
enough for there to need to be an abort mechanism.  This is in contrast
to file I/O which can block.

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.


Race conditions obviously need to be handled, which they will be
automatically in the current code.  GDB will write an \003 to the
serial connection, which as I describe below, gdbserver will
immediately consume and process, and then report next time it's asked
to wait (i.e. when the qSymbol is done).


> >That keeps the stub implementation much simpler.  And the client
> >implementation is easy using blocked signals.
> 
> >Implementing something as you describe would be a bit trickier in
> >gdbserver; I'd have to force-stop all threads and then fake a SIGINT
> >event.
> 
> 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.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer