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: MI handshaking


On Wed, Nov 17, 2004 at 08:35:32PM -0500, Alain Magloire wrote:
> > 
> > On Wed, Nov 17, 2004 at 10:17:57AM -0500, Alain Magloire wrote:
> > > > 
> > > > On Sat, Nov 13, 2004 at 10:57:33AM +0200, Eli Zaretskii wrote:
> > > > > > Date: Fri, 12 Nov 2004 17:57:30 -0500
> > > > > > From: Andrew Cagney <cagney@gnu.org>
> > > > > > Cc: Bob Rossi <bob@brasko.net>, Nick Roberts <nick@nick.uklinux.net>,
> > > > > >         gdb-patches@sources.redhat.com
> > > > > > 
> > > > > > > =mi-handshake,versions=[mi1,mi2,mi3],stable=[mi2]
> > > > > > 
> > > > > > Yes, thanks for the correction with ``=''.   But not 
> > > > > > ``versions=[mi1,mi2,mi3]'' that's too much and misleading information.
> > > > > > 
> > > > > > I think the objective here needs to be to provide as much information as 
> > > > > > possible about what version of GDB and MI is running.  Hence the:
> > > > > > 
> > > > > > 	version="mi2"
> > > > > > 
> > > > > > (where hopefully VERSION version is a member of STABLE :-)
> > > > > 
> > > > > We've been through this discussion, and the only suggestion that
> > > > > brought a consensus was to print all the supported MI versions, not
> > > > > just one.  Let's not reopen that discussion again, even if the result
> > > > > looks ``too much and misleading''.  (Why ``misleading'', btw?)
> > > > 
> > > > Yeah, anyways it doesn't really matter for now. GDB only supports one
> > > > version, and I have a feeling it will stay that way for a long time.
> > > > 
> > > 
> > > sigh ... sorry for being dense (hopefully this will not be a long thread)
> > > but why are you keep on saying: "GDB only supports one version"
> > > for example, I have gdb-6.1.x and I can start
> > > # gdb -i mi1
> > > # gdb -i mi2
> > > # gdb -i mi3
> > > 
> > > that it is more then one version?
> > 
> > oops, sorry, I meant to say that GDB supports only 1 stable MI version.
> > This is only relavent when discussing what GDB should do when the user
> > starts with 'gdb -i=mi'.
> > 
> > I see 2 needs stemming from this patch.
> >    
> >    - I need the handshaking to happen before any other I/O.
> >      This allows my front end to determine the protocol that is going to
> >      be used by GDB.
> > 
> >    - Alain, it seems like you need this command to be available after
> >      the fact. Even though this seems unintuitive to me, I understand
> >      that it's not a perfect world, and this info could be useful later
> >      on, especially if you are not responsible for staring GDB.
> > 
> 
> Yes.
> Very true, it is not a perfect world but I also think it is rather inconsistent
> that important information is lost once the screen scrolled away,
> i.e. no way to retrieve it, beside restarting ...
> 
> > It seems as if there is two parts to this patch. The first part does the
> > handshaking, and that takes care of the protocol that should be used.
> > Here, GDB will give all of the info necessary to help the front end determine
> > the protocol that it wants to use. For instance, the protocols possible,
> > the build date, the GDB version, ...
> > 
> > Also, as a second part, a new MI command could be added, that simply
> > repeats all of the info determined from the handshaking functionality.
> > This would allow front ends to query the information later on, if for
> > some reason it couldn't do it originally. Note however, this would not
> > repeat the handshaking, and the version of MI being used can not be
> > changed. 
> > 
> 
> Yes.
> I did not advocate to be able to change MI versions at runtime.
> That would be overkill, i.e. it would be simpler to restart gdb
> then to try to code that complexity with little benifits, IMHO
> 
> > Would this be OK for everyone?
> > 
> 
> That would be good, and the proposed format suits me fine
> mi-version="mi2",...
> 
> Thanks Bob for looking at this.

I've been very busy, so sorry about the delay.

I'll look into what we discussed here and come up with something that
fits all the new needs. Does Jim care about any of this?

Thanks,
Bob Rossi
> 


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