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

Daniel Jacobowitz
2004-03-11T20:16:33Z

On Thu, Mar 11, 2004 at 03:05:50PM -0500, Andrew Cagney wrote:
> >I'd like to propose the attached as an extension to the remote protocol.
> >The code implementing this change is here:
> > http://sources.redhat.com/ml/gdb-patches/2004-02/msg00000.html
> >
> >>From my original post:
> > As Amit Kale mentioned in December, to support NPTL gdbserver needs to
> > look up symbols during remote_wait. The existing qSymbol model assumes
> > that only at objfile loads (i.e. during td_ta_new) do we need to look up
> > symbols; NPTL looks up symbols lazily when it needs them, which includes
> > at the creation of the first child thread. This patch (which, I know,
> > needs a matching change for the manual) allows qSymbol: queries as a
> > response to remote_wait, in much the same way as the file I/O protocol.
> >
> >So here's the manual page and a description of the change. Thoughts?
>
> This isn't sufficient:
>
> >+@item qSymbol:@var{sym_name}
> >+
> >+The target is requesting the address of a symbol. @value{GDBN} replies
> >with
> >+a @code{qSymbol} packet providing the address of @var{sym_name} if
> >available
> >+(@pxref{General Query Packets}).
> >+
> >+As with @code{F}, this response does not terminate the current resume
> >+action. @value{GDBN} continues waiting for another stop packet.
> >+
>
> 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

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.