Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Nick Roberts <nickrob@snap.net.nz>
To: Vladimir Prus <vladimir@codesourcery.com>
Cc: Pawel Piech <pawel.piech@windriver.com>, gdb@sources.redhat.com
Subject: Evolution of GDB/MI [was Re: MI non-stop interface details]
Date: Fri, 02 May 2008 01:23:00 -0000	[thread overview]
Message-ID: <18458.27882.797522.892907@kahikatea.snap.net.nz> (raw)
In-Reply-To: <200805012211.51656.vladimir@codesourcery.com>

 > >                                                      Through its many 
 > > versions GDB has freely changed (or "cleaned up") the MI protocol in 
 > > subtle ways without warning (e.g. adding quotes around the condition 
 > > parameter in -break-condition).  This creates headaches for clients, and  
 > > can ultimately make the client code difficult to maintain. A perfect 
 > > example of this is the CDI-GDB Eclipse integration.  While it has other 
 > > architectural issues, the myriad of workarounds for various GDB versions 
 > > in it makes it difficult to know whether a change for latest GDB version 
 > > won't break support for old GDB versions.  What I don't think GDB 
 > > maintainers realize is that ultimately this policy does a lot of harm to 
 > > GDB adoption and GDB's reputation in the larger community.

I don't think it's a question of awareness.  Maintaining backward compatibility
is extra work for GDB developers while finding workarounds for different
versions is extra work for frontend developers.  While the former group tries
to consider the latter (united we stand, divided we fall) I think frontend
developers really need to take an active part in Gdb development if they expect
any kind of smooth ride.  Up till now, that has not really been the case for
Eclipse, although recently it does appear to be changing.

 > >                                                             I would 
 > > guess that most users of GDB have some kind of graphical interface and 
 > > their quality is linked to perception of quality of GDB.   GDB/MI is a 
 > > published protocol with many users, and I wish that this fact had more 
 > > significance to its maintainers.


 > GDB/MI is actually not a finished published protocol -- it's work in
 > progress.  Unfortunately, frontend maintainers tended to read between the
 > lines, and guess the behaviour and accepted input instead of asking
 > here. And in cases where what they've read between the lines does not
 > correspond to what GDB developers means, the result is a buggy frontend :-)

Well, it's described in the manual, so I guess it is published in that sense.
We have attempted to describe how GDB/MI might reasonably change in the future.
Perhaps now is the time to expand on that part of the documentation.

-- 
Nick                                           http://www.inet.net.nz/~nickrob


  parent reply	other threads:[~2008-05-02  1:23 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-04-26 18:09 MI non-stop interface details Vladimir Prus
2008-04-26 18:16 ` Doug Evans
2008-04-26 19:49   ` Vladimir Prus
2008-04-30  7:18     ` Marc Khouzam
2008-04-28 16:21 ` Pedro Alves
2008-04-29 19:21   ` Vladimir Prus
2008-04-29 20:04     ` Pedro Alves
2008-04-30  7:00       ` Pawel Piech
2008-05-01 16:15         ` Vladimir Prus
2008-05-01 16:31           ` Pawel Piech
2008-05-01 16:38             ` Vladimir Prus
2008-05-01 16:58               ` Pawel Piech
     [not found]               ` <4819F4D4.4010305@windriver.com>
2008-05-01 17:00                 ` Vladimir Prus
2008-05-01 17:53                   ` Pawel Piech
2008-05-01 18:12                     ` Vladimir Prus
2008-05-01 18:37                       ` Pawel Piech
2008-05-02  1:23                       ` Nick Roberts [this message]
2008-04-30 14:23       ` Marc Khouzam
2008-04-30 17:21         ` Pedro Alves
     [not found]         ` <200804301117.42633.vladimir@codesourcery.com>
     [not found]           ` <4818AA58.4040201@windriver.com>
2008-05-01 17:11             ` Vladimir Prus
2008-05-01 18:08               ` Pawel Piech
2008-05-02 14:21                 ` Vladimir Prus
2008-05-02 16:59                   ` Pawel Piech
2008-05-02 17:13                     ` Vladimir Prus
     [not found]                       ` <481B4FDC.4010802@windriver.com>
2008-05-02 17:36                         ` Vladimir Prus
2008-05-02 18:00                           ` Pawel Piech
2008-05-02 18:19                             ` Vladimir Prus
2008-05-02 18:36                               ` Pawel Piech
2008-04-29  3:14 ` Pawel Piech
     [not found] ` <200804301059.44112.vladimir@codesourcery.com>
     [not found]   ` <200804301534.48779.pedro@codesourcery.com>
2008-05-01 17:22     ` Vladimir Prus
2008-05-01 17:52       ` Pedro Alves

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=18458.27882.797522.892907@kahikatea.snap.net.nz \
    --to=nickrob@snap.net.nz \
    --cc=gdb@sources.redhat.com \
    --cc=pawel.piech@windriver.com \
    --cc=vladimir@codesourcery.com \
    /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