Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Andrew Cagney <ac131313@cygnus.com>
To: Michael Snyder <msnyder@cygnus.com>
Cc: gdb-patches@sources.redhat.com, jtc@redback.com
Subject: Re: [RFC] Extend remote protocol to allow symbol look-up service.
Date: Fri, 27 Apr 2001 08:20:00 -0000	[thread overview]
Message-ID: <3AE98DE1.84FE55D5@cygnus.com> (raw)
In-Reply-To: <3AE8928A.18E07030@cygnus.com>

> Does anyone else have an opinion?  I don't like unreadable messages.

The packet intent is still readable, just not the symbol.  I know its a
pain.  However I'd rather that pain then have to later go and
re-implement the packet because it did turn up problems. Look at the
constant retro-fitting required by the X packet.

> > Is the protocol stateless?  That is, would repeating the query:
> >
> >         qSymbol::__pthread_max_threads
> >
> > always return the same value?

Oops, not quite the right question.

> It's not stateless; both the target and the debugger have state.
> On the debugger, the 'state' is whether the symbol is available or not.
> On the target, the state is whether this symbol's value has been obtained.
> Also whether it has been requested since the last shared library event.
> The target should ask for a given symbol only once per shared library
> event.  There won't be any harm in asking for the same symbol twice --
> except for the possibility of getting into an infinite loop.

Would the following sequence (first line is GDB -> target) occure:

	-> qSymbol:4321:sym1
	<- qSymbol:sym2

	-> qSymbol:4321:sym1
	<- qSymbol:sym2

	-> qSymbol:1234:sym2
	<- qSymbol:sym3

From what you've said, I think that is the case and that I think that is
the correct behavour. The target should be using the last symbol it
received from GDB to determine the next symbol.  It should not be solely
reliant on internal state.

Compare this to the ThreadInfo packet :-(

--

What about a simplification along the lines of:

	-> qSymbol
	<- ""	Don't know what you're talking about
	<- OK	Thanks, that's all
	<- HEX-SYMBOL
		please try to tell me the value of the symbol.

	-> qSymbol:BE-HEX-VAL:HEX-SYMBOL
	<- ""	Don't know what you're talking about
	<- OK	Thanks, that's all
	<- HEX-SYMBOL
		please try to tell me the value of the symbol.

With a note that the target must use the packet contents when
determining the next symbol to request query.

	Andrew


      reply	other threads:[~2001-04-27  8:20 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-04-17 16:29 Michael Snyder
2001-04-17 18:50 ` Jonathan Larmour
2001-04-19 13:40 ` Jim Blandy
2001-04-19 15:07   ` Michael Snyder
2001-04-21 16:35 ` Andrew Cagney
2001-04-26 14:22   ` Michael Snyder
2001-04-27  7:54     ` Andrew Cagney
2001-04-21 16:40 ` Andrew Cagney
2001-04-26 14:26   ` Michael Snyder
2001-04-27  8:20     ` Andrew Cagney [this message]

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=3AE98DE1.84FE55D5@cygnus.com \
    --to=ac131313@cygnus.com \
    --cc=gdb-patches@sources.redhat.com \
    --cc=jtc@redback.com \
    --cc=msnyder@cygnus.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