From: Bob Rossi <bob_rossi@cox.net>
To: Andrew Cagney <ac131313@redhat.com>
Cc: Nick Roberts <nick@nick.uklinux.net>, gdb-patches@sources.redhat.com
Subject: Re: [rfc] Annotation level THREE
Date: Tue, 18 Mar 2003 20:17:00 -0000 [thread overview]
Message-ID: <20030318201727.GA11746@white> (raw)
In-Reply-To: <3E774292.8070603@redhat.com>
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
next prev parent reply other threads:[~2003-03-18 20:17 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-03-11 23:37 Andrew Cagney
2003-03-12 18:54 ` David Carlton
2003-03-12 19:04 ` Andrew Cagney
2003-03-14 0:08 ` Nick Roberts
2003-03-17 0:23 ` Andrew Cagney
2003-03-17 20:07 ` Nick Roberts
2003-03-17 20:38 ` Andrew Cagney
2003-03-18 10:31 ` Nick Roberts
2003-03-18 15:29 ` Andrew Cagney
2003-03-18 16:00 ` Andrew Cagney
2003-03-18 20:17 ` Bob Rossi [this message]
2003-03-12 6:09 Michael Elizabeth Chastain
2003-03-12 14:50 ` Andrew Cagney
2003-03-12 14:56 ` Daniel Jacobowitz
2003-03-12 17:04 ` David Carlton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20030318201727.GA11746@white \
--to=bob_rossi@cox.net \
--cc=ac131313@redhat.com \
--cc=gdb-patches@sources.redhat.com \
--cc=nick@nick.uklinux.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox