Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Daniel Jacobowitz <drow@false.org>
To: Andrew Cagney <cagney@gnu.org>
Cc: gdb@sources.redhat.com
Subject: Re: [remote protocol] Allow qSymbol response to continue packets
Date: Thu, 11 Mar 2004 20:16:00 -0000	[thread overview]
Message-ID: <20040311201632.GA26795@nevyn.them.org> (raw)
In-Reply-To: <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


  reply	other threads:[~2004-03-11 20:16 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-03-06 23:52 Daniel Jacobowitz
2004-03-07  5:45 ` Eli Zaretskii
2004-03-11 20:06 ` Andrew Cagney
2004-03-11 20:16   ` Daniel Jacobowitz [this message]
2004-03-11 21:27     ` Andrew Cagney
2004-03-11 21:40       ` Daniel Jacobowitz
2004-03-11 23:21         ` Andrew Cagney
2004-03-11 23:38           ` Daniel Jacobowitz
2004-03-12 19:45             ` Daniel Jacobowitz
2004-03-17 16:07             ` Andrew Cagney

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20040311201632.GA26795@nevyn.them.org \
    --to=drow@false.org \
    --cc=cagney@gnu.org \
    --cc=gdb@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox