This is the mail archive of the gdb-patches@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: RFA (?) Annotate Level 3 patch


> 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


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