This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: [remote protocol] Allow qSymbol response to continue packets
- From: Daniel Jacobowitz <drow at false dot org>
- To: Andrew Cagney <cagney at gnu dot org>
- Cc: gdb at sources dot redhat dot com
- Date: Thu, 11 Mar 2004 15:16:32 -0500
- Subject: Re: [remote protocol] Allow qSymbol response to continue packets
- References: <20040306235253.GA10376@nevyn.them.org> <4050C69E.7060906@gnu.org>
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.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer