This is the mail archive of the gdb@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: probing GDB for MI versions


>For instance, XML allows the first line of the document to have the
>version number. From then on, it can use the correct parser to process
>the document. If the version number is not there, it can only guess at
>what's in the document, and errors can occcur. Basically, the version
>number is in a format the client can understand and then the client can
>choose the appropriate parser based off of this.
>
>I think adding an MI command to get the version is not the solution to
>this problem. Calling an MI command assumes that you already know the
>protocol, and then you can call the MI function. Otherwise, you are not
>necessarily handshaking, but you have to write the adhoc parser to get
>the information you need.
>
>For instance, if GDB supported 1 stable MI protocol, if it is an
>official release or a CVS snapshot, then the first thing GDB could
>output to the front end is the version of MI that it is communicating.
>
>If we wanted to be even more verbose, we could 
>
>   * define a syntax for an MI header that communicated to the front 
>     end all of the necessary things it would need to know before 
>     initializing it's protocol.
>
>   * we could always handshake using the MI2 protocol, even though the
>     protocol that GDB supports is a higher version. 
>     
>For option 2, this means that GDB would not necessarily support MI2, 
>but it would handshake in that protocol, since it will probably never 
>need to change for backward incompatibilities. This has the downside 
>of forcing new front ends to be able to implement the MI2 protocol, 
>which is probably not a good idea.

Another example is the Auto-sense of Ethernet. Two partners start
communicating with 10MBit as the least common denominator of
Ethernet. Then they find they can both speak 100MBit and switch
to this. Compared to gdb this would mean to start gdb with mi1,
negotiate the version and then possibly switch to some higher
mi version. But I think the switching is the part that doesn't work
here (without restarting gdb, correct me if I'm wrong). 

Is it possbile to switch the mi version on the fly? If not, is this even
considered a possible future extension? Or is it considered unneeded
and wasted manpower as a working solution (restarting gdb) already
exists?

(I don't need this for myself. As I have to deliver a cross-compiled
gdb with possibly some changes I will always know what mi version
it can speak.)

Thanks

bye  Fabi



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