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


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.

Andrew



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