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: Bob Rossi <bob at brasko dot net>
- To: gdb-patches at sources dot redhat dot com
- Cc: Daniel Jacobowitz <drow at false dot org>
- Date: Thu, 5 May 2005 12:22:33 -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>
> Well, I do understand your point here but I'd prefer that all fullname
> checks ensure that the path be absolute. The more I think about it, I
> should probably make a variable called 'fullname_output' in the
> testsuite that contains the regex output of a fullname. How does this
> sound?
>
> > > As promised, here is an updated patch set with the regex
> > > changes you suggested, plus checking for a little more directory
> > > information with respect to the fullname path, to the extent
> > > that we can be sure the test case still passes in all environments.
> >
> > I don't think adding fullname= to the -i=mi2 output is a good idea; MI2
> > is supposed to be stable. Bob, what do you think? Anyone else?
>
> 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?
Thanks,
Bob Rossi