Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Michael Snyder <msnyder@cygnus.com>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [RFA] Remote symbol look-up (resubmission)
Date: Mon, 21 May 2001 15:30:00 -0000	[thread overview]
Message-ID: <3B099713.8F689955@cygnus.com> (raw)
In-Reply-To: <3B049A7C.1040306@cygnus.com>

Andrew Cagney wrote:
> 
> > Are you saying that there is going to need to be an extra parameter (the
> >> shared library name) added to the target->gdb symbol request on Solaris?
> >
> >
> > No, I'm saying it could potentially be useful to pass back the filename.
> > Not that I think it is necessary.  The underlying mechanism that would
> > use this method on Solaris has a symbol-file-name argument.  We don't
> > currently use it.  Someday we might.  Just keeping the option open.
> 
> In that case I'd prefer at this point to leave the the symbol-file
> passing out.  Instead just stick to a single simple qSymbol packet.  The
> behavour would be:
> 
>         To start a transaction sequence:
> 
>                 -> qSymbol
> 
>         It could even be:
> 
>                 -> qSymbol::
> 
>         If you want simplicity and consistency.
> 
>         The reply would be as you proposed:
> 
>                 <- ""
>                         Not recognized
>                 <- "OK"
>                         Recognized but not now
>                 <- <the-I-want-a-symbol-address>
>                         As you've described
> 
>         From then on it is:
> 
>                 -> qSymbol:<addr>:<symbol>
> 
> I don't think it is a good idea to try to include a mechanism for
> passing back and forth the name of an object file until there is a
> demonstrated need for such a feature.
> 
> The reason for this is that, in the past GDB has incorporated what look
> like very reasonable idea's only to find that, when someone uses them,
> they are insufficient.

Andrew, if I have to change the QSymbol:value:name message from a
Q to a q, it is going to cause me non-trivial grief and code rewriting.
Are you going to insist on this?  To me it seems like a "set" message,
not a "query" message.  It is telling the target that symbol <name>
has value <value>, not asking the target something.

I need the first message that opens the dialogue to be unambiguously
unique, so that I know that I have to request the _first_ unknown
symbol, rather than the _next_ unknown symbol.  I don't want the
message that says "start requesting symbols" to be the same as the
message that says "here's your next symbol, and by the way you may
request another".

Michael


  parent reply	other threads:[~2001-05-21 15:30 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-05-11 10:26 Michael Snyder
2001-05-11 12:39 ` Eli Zaretskii
2001-05-11 18:51   ` Michael Snyder
2001-05-11 19:57 ` Andrew Cagney
2001-05-14 11:18   ` Michael Snyder
2001-05-14 13:37     ` Andrew Cagney
2001-05-14 14:34       ` Michael Snyder
2001-05-17 20:44         ` Andrew Cagney
2001-05-21 15:12           ` Michael Snyder
2001-05-21 15:30           ` Michael Snyder [this message]
2001-06-06  9: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=3B099713.8F689955@cygnus.com \
    --to=msnyder@cygnus.com \
    --cc=ac131313@cygnus.com \
    --cc=gdb-patches@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