This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]