This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [RFC] fullname attribute for GDB/MI stack frames
- From: Daniel Jacobowitz <drow at false dot org>
- To: gdb-patches at sources dot redhat dot com
- Date: Thu, 5 May 2005 12:25:44 -0400
- Subject: Re: [RFC] fullname attribute for GDB/MI stack frames
- References: <ECCC6E9907B4CD4A83260A191A91F20E22C6D2@wampa.office.slickedit.com> <20050430191755.GF7009@nevyn.them.org> <20050501021945.GA19962@white> <20050505162233.GD31111@white>
On Thu, May 05, 2005 at 12:22:33PM -0400, Bob Rossi wrote:
> > As far as i understand, it is acceptable to add new fields to a stable
> > version of MI. It is the parsers responsibility to ignore MI fields that
> > they are unfamiliar with. I also understand that it is acceptable to add
> > new commands to an MI version. Making either of the 2 changes above does
> > not effect the version number of the MI release (AFAIK).
> >
> > With that said, I'm not quite sure what model Andrew had in mind
> > when releasing the MI versions. Here is 2 possibilities,
> >
> > Originally there is mi-. Once it becomes stable it is released as mi2-.
> > mi2- is never touched again, accept for bug fixes. All development and
> > new features is done on mi-. When mi- becomes stable again it is turned
> > into mi3-.
> >
> > Originally there is mi-. Once it becomes stable it is released as mi2-.
> > Any changes compatible with the MI2 protocol should be merged into the
> > mi- and mi2- testcases. Changes that are not compatible with mi2 should
> > be merged into mi-. When mi- becomes stable enough it could be moved
> > into mi3-.
> >
> > I prefer the second model. I think it is more flexible and would allow
> > for features to get into the MI protocol faster.
>
> Ping, any decision on this? I need to know if I should be modifing mi2
> testcases or just mi?
I had no objection to your explanation. I thought you were just adding
the regex and I was going to update the testcases?
--
Daniel Jacobowitz
CodeSourcery, LLC