This is the mail archive of the gdb@sourceware.org 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: asynchronous MI output commands


On Sun, May 07, 2006 at 08:29:35PM -0400, Bob Rossi wrote:
> OK. I start with the MI output. I use bison to convert that into an
> abstract parse tree. Now, I am working on a solution to take the
> abstract parse tree and turn it into a simple to use representation for
> the front end (ADT). I gave the example earlier, taking the abstract parse
> tree for -file-list-exec-source-file 
>   ^done,line="26",file="test.c",fullname="/home/bob/cvs/cgdb/cgdb.mi/builddir/test.c"
> and turn that into
>   struct file_list_exec_source_file
>   {
>     int line;
>     char *file;
>     char *fullname;
>   };
>   struct file_list_exec_source_file result = { 26, "test.c", "/home..."};

[What's ADT mean then?  The "A" can't be abstract, there's nothing
abstract about this.]

> > You don't
> > need to know what the data is to do that.  If you want to create
> > individual response structure types for each supported MI command, then
> > you ought to know what command is being answered (see my mail a moment
> > ago for why), and be able to convert the _abstract_ tree into an
> > appropriate _concrete_ structure.
> 
> Yes, I agree, if I knew the MI input command, I could use that to
> determine what type of command I was looking at. If I won't be allowed
> to add the command to the output record, then this is what I will do.
> 
> However, I would like to be able to do this with out knowing the MI input 
> command. First, it makes the code more modular that takes the MI output
> and turns it into something meaningful. Second, it's easy to gather a
> bunch of MI output commands from the test suite or from FE user's with
> FE problem, and parse just that output. Third, it validates that what
> the user requested is what the user is getting. It is possible that the
> FE and GDB could get mixed up I'm assumming.

You're trying to turn a response into a meaningful message without
knowing what it's a response to.  I just don't see the benefit of this;
although people keep telling me it's harder than I understand, I
still haven't seen an example that I consider plausible.

It's easy to gather output from e.g. the testsuite, true.  But it's
equally easy to record the commands - just about everything is going to
go through mi_gdb_test, or you could even write a proxy between the
testsuite and GDB which logged, or add the logging to GDB directly.  I
know Eclipse's MI protocol log includes the commands it sent.

Your third point is valid, but does not seem particularly important to
me.  If it's wrong, it's wrong.  GDB would just have to stitch the
command name on at the end right before outputing the result record,
so that wouldn't gain you much at all.

> Anyways, Daniel, thanks for taking time out of your busy schedule to
> think about this issue. If you simply don't want something like this in
> MI right now, I'll find a way to match the input with the output.

I'm not supreme dictator of this stuff; someone else is welcome to step
in and disagree.  I'm just not convinced, either.

-- 
Daniel Jacobowitz
CodeSourcery


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