Re: [RFC] fullname attribute for GDB/MI stack frames

[Bob Rossi <bob@brasko.net>]

On Sat, Apr 30, 2005 at 03:17:55PM -0400, Daniel Jacobowitz wrote:
> On Fri, Apr 01, 2005 at 02:13:33PM -0500, Dennis Brueni wrote:
> > > Again, for the fullname regex, I would recommend using the 
> > > same regex used in mi-file.exp. This would be like 
> > > fullname="/.*basics.c" This forces the regex to ensure that 
> > > the path is absolute, which the check you have does not.
> 
> Will GDB always output absolute paths that start with "/"?  What about
> non-Cygwin Windows for example?  DJGPP?

Like Dennis noted, it could be possible that the fullname might not
start with a "/". I originally posted the patch with the fullname
starting with a "/", and since then, there hasn't been any complaints.
If there is a better regex that ensures that the fullname is absolute
I'd be happy to change the mi-file.exp test to it.

> In any case, if you want to verify that fullname starts with a
> full path, it can be an independent test.  It doesn't need to live in
> every other MI stack test.

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.

Thanks,
Bob Rossi