From: Bob Rossi <bob@brasko.net>
To: Jim Ingham <jingham@apple.com>
Cc: Eli Zaretskii <eliz@gnu.org>,
mec.gnu@mindspring.com, gdb@sources.redhat.com
Subject: Re: GDB/MI Output Syntax
Date: Fri, 07 Jan 2005 01:12:00 -0000 [thread overview]
Message-ID: <20050107011211.GB29435@white> (raw)
In-Reply-To: <4CE93165-C27F-4CF6-90B8-7632A7BD2672@apple.com>
On Thu, Jan 06, 2005 at 04:36:13PM -0800, Jim Ingham wrote:
> Sorry for not responding, we're really busy here right now.
>
> I don't think there is any way to use your parser that won't involve
> changing the testsuite files. After all, they are just passing regular
> expressions, and unless you are ALSO willing to write a parser that
> turns the mi testsuite regular expressions into some sensible form (not
> something I would suggest) you are going to have to rewrite these
> tests.
OK, so rewriting the tests is fine. They are not very complicated.
> I was more thinking of this as a project that you would use to write
> new tests, and then any time a change in the mi output broke a test
> case, you could rewrite it using the new form - since you are going to
> have to rewrite it anyway...
That's sounds OK. However, I would like to rewrite a few of them now, so
that I can test that the parser is working.
> The way that I was thinking to use the parser, is to write a command
> like: "gdb_mi_parse_output" that would take the mi output, run your
> parser on it, and turn the result into some Tcl data structure. This
> would be a C based command, so we would have to build a little Tcl
> extension to do this, and include it with gdb when we ran the test
> suite.
Here's the deal, I already have the C function that takes an MI output
command, parses it, and returns a tree that represents the command.
int gdbmi_parser_parse_string (
gdbmi_parser_ptr parser, /* a gdbmi parser context */
const char *mi_command, /* command the parser should parse */
gdbmi_output_ptr *pt ); /* The parse tree */
If Tcl is like C (struct, enum's, union's) I could easily put the parse
tree declaration in some common file and generate both the C and the Tcl
data structures. This part could be done in just a few days if I could
get some guidance on how Tcl works.
> The mi output is all basically just nested lists, so you could probably
> express it as a nested list pretty easily. I'd have to think a bit
> about how to design this well. Anyway, then you could rewrite the test
> suite cases to just pull fields out of the Tcl data structure, and see
> if the values were what was expected.
This part I could do also. In fact, I need to do essentially this to
make my front end work. It's all the same code. I think taking this step
would do a lot in the sense of standardizing the output of GDB/MI.
> Unfortunately, I am definitely not going to have any time to work on
> this in the next little while, however.
If you could help me with some technical details, I'd be happy to do the
rest of the work. Is this possible or are you just to maxed out?
Thanks,
Bob Rossi
next prev parent reply other threads:[~2005-01-07 1:12 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1093622671.2836.ezmlm@sources.redhat.com>
2004-08-27 17:56 ` Jim Ingham
2004-08-27 19:12 ` Michael Chastain
2005-01-05 23:27 ` Bob Rossi
2005-01-06 4:48 ` Eli Zaretskii
2005-01-06 23:31 ` Bob Rossi
2005-01-07 0:36 ` Jim Ingham
2005-01-07 1:12 ` Bob Rossi [this message]
2005-01-07 3:12 ` Russell Shaw
2005-01-11 19:35 ` Bob Rossi
2005-01-13 2:23 ` Bob Rossi
2005-01-13 2:46 ` Intrusive GDB Symbol Lookup when debugging remotely David Steven Trollope
2005-01-22 4:25 ` Dave Trollope
2005-01-24 19:48 ` Andrew Cagney
2005-01-24 19:54 ` David Steven Trollope
2005-03-18 16:29 ` Linux Realtime Scheduling Option David Steven Trollope
2005-03-18 18:12 ` Daniel Jacobowitz
2005-03-21 19:21 ` David Steven Trollope
2005-03-21 19:33 ` Daniel Jacobowitz
2005-03-22 3:04 ` Dave Trollope
2005-03-22 4:06 ` Daniel Jacobowitz
2005-01-06 0:28 GDB/MI Output Syntax Paul Schlie
2005-01-06 0:32 ` Kip Macy
2005-01-06 0:49 ` Paul Schlie
2005-01-06 1:10 ` Bob Rossi
2005-01-06 1:36 ` Paul Schlie
-- strict thread matches above, loose matches on Subject: below --
2004-08-25 15:44 Bob Rossi
2004-08-25 15:57 ` Michael Chastain
2004-08-25 19:37 ` Bob Rossi
2004-08-26 14:01 ` Michael Chastain
2004-08-26 18:31 ` Bob Rossi
2004-08-26 20:44 ` Michael Chastain
2004-08-26 20:52 ` Keith Seitz
2004-08-26 22:16 ` Michael Chastain
2004-08-26 22:03 ` Bob Rossi
2004-08-26 23:06 ` Michael Chastain
2004-08-26 21:13 ` Andrew Cagney
2004-08-26 21:25 ` Bob Rossi
2004-08-26 22:46 ` Michael Chastain
2004-08-27 10:14 ` Eli Zaretskii
2004-08-26 22:41 ` Michael Chastain
2004-08-24 3:12 Bob Rossi
2004-08-24 4:15 ` Michael Chastain
2004-08-24 12:30 ` Bob Rossi
2004-08-24 12:50 ` Michael Chastain
2004-08-24 18:59 ` Andrew Cagney
2004-08-24 19:07 ` Bob Rossi
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=20050107011211.GB29435@white \
--to=bob@brasko.net \
--cc=eliz@gnu.org \
--cc=gdb@sources.redhat.com \
--cc=jingham@apple.com \
--cc=mec.gnu@mindspring.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