From: Bob Rossi <bob@brasko.net>
To: Nick Roberts <nick@nick.uklinux.net>
Cc: Andrew Cagney <cagney@gnu.org>, gdb-patches@sources.redhat.com
Subject: Re: RFA (?) Annotate Level 3 patch
Date: Thu, 12 Feb 2004 22:34:00 -0000 [thread overview]
Message-ID: <20040212223405.GA4259@white> (raw)
In-Reply-To: <16427.62345.989794.926455@nick.uklinux.net>
> On a related matter, as the Machine Interface evolves, Emacs will have to do
> different things for different versions of GDB, so it would be helpful if
> "show version" ("-gdb-show version") or a related command gave a formally
> defined increasing version number. In Emacs, the last release is 21.3.1 and
> the version in CVS is 21.3.50. In GDB, the last release is 6.0 but the version
> in CVS is 2004-02-01-cvs, say. Also releases, like 5.3postxxxx.. exist.
This is also a real concern of mine. I would like to see a formal
printing of GDB/MI's version number. I think that starting gdb like
gdb --show-gdbmi-version should output the version in an MI parable
way.
Also, another problem exists which Nick brings up. When distro's package
GDB from CVS ( debian ), how should the front end determine what MI
version is being used? It is possible that the version number has not
formally changed, however several MI commands might have been modified.
In this case, it would be necessary to make all commands backwards
compatible, and the front end wouldn't be able to take advantage of
commands that might be useful.
An approach to solving this could be, when the front end wants to know
the version, GDB could print the MI version of each function it
supports. So,
gdb --show-gdbmi-version
^done,[{mi_function="-break-info",version=1},{mi_function="-break-list",version=2}]
Would this be overkill?
Also, as each MI command changes, the documentation must provide the
interface for that MI command for each version.
Bob Rossi
prev parent reply other threads:[~2004-02-12 22:34 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-08-05 20:10 Nick Roberts
2004-01-27 20:28 ` Andrew Cagney
2004-01-29 0:20 ` Annotations Nick Roberts
2004-02-02 22:09 ` RFA (?) Annotate Level 3 patch Nick Roberts
2004-02-10 23:40 ` Andrew Cagney
2004-02-12 21:53 ` Nick Roberts
2004-02-12 22:34 ` Bob Rossi [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=20040212223405.GA4259@white \
--to=bob@brasko.net \
--cc=cagney@gnu.org \
--cc=gdb-patches@sources.redhat.com \
--cc=nick@nick.uklinux.net \
/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