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: [RFC] fullname attribute for GDB/MI stack frames


> 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


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