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] Annotation level THREE


On Tue, Mar 18, 2003 at 11:00:18AM -0500, Andrew Cagney wrote:
> >>>  > The above list also contains thing like field-{begin,end}, 
> > > >  > array-section-{begin,end} et.al.  Why are they needed.
> > > > 
> > > > I use them to parse the output. They could probably go, if 
> > necessary, but
> > > > others that you plan to take out *are* needed.
> > > 
> > > Can you please be more specific?
> >
> >Perhaps I could turn that question round. Which annotations are you 
> >planning
> >to keep?
> 
> I think annotations can be split into two categores:
> 
> - events
> These let GDB notify the GUI of internal state changes.
> 
> - markups
> These try to make CLI output, intended solely for a human, machine 
> parsable.
> 
> The events remain (target changed, breakpoint created, ....).  The 
> markups are removed (*-{begin,end})
> 
> Andrew
> 

Here is my humble opinion.

I do see a problem with annotate level 3. I don't understand why GDB
should introduce another level of complexity to the annotation problem.
( The problem being the switch from annotation to mi ).

It doesn't really make sense to me that several releases of GDB will
support an annotation level of 3.I think it would be great if 
annotations were deprecated after MI was fully ready to take its place.
If MI is "ready" to replace annotations, then it should. I don't see how
removing several annotations really saves the GDB developers anything.

I think the proof that MI is ready is to see at least one console
implementation of a front end to GDB. I don't expect to see proof. I do
however wonder what kind of a mess we will be in if front ends can not
make a console implementation complete with a certain version of GDB
because of some lack of support in MI. To stack problems on top of that,
the front end will be using a combination of annotation/MI commands
which to me seems to complicated. After all, this is a simple problem,
and we are smart people :).

1. In the future all front ends will have to put up with supporting the
possibility of having annotation level 3. This seems like it would be a
more complex way to determine problems with the front end.

2. Front ends will at some point
   a. use only annotations to communicate with GDB.
   b. use a hybrid of annotations / MI to communicate with GDB.
   c. use only MI to communicate with GDB.
   
   This seems to be an overly complex way to transition between the
   two. It seems as if annotations should stay until MI is ready to be
   used to replace all of the annotations.
   Why would we want to place part (b) on front ends. That penalty has
   an order of magnitude of N for front ends that will use annotate level
   2 to communicate with GDB. This is a clear violation of the DRY 
   principle.

3. Someone like me will start to write a front end and say
   "Hey, annotation level 3 is cool, I will use it to write a front end
   to GDB". Then we will have another problem. :)

Bob Rossi


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