This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [RFC] GDB/MI -symbol-* functions
- From: Keith Seitz <keiths at redhat dot com>
- To: Jelmer Vernooij <jelmer at samba dot org>
- Cc: gdb-patches at sources dot redhat dot com
- Date: Mon, 16 Sep 2002 16:02:28 -0700 (PDT)
- Subject: Re: [RFC] GDB/MI -symbol-* functions
On Sun, 15 Sep 2002, Jelmer Vernooij wrote:
> -symbol-type seems to already be somewhat implemented in
> mi/mi-cmd-var.c - would implementing this function be desired?
Well, if something that does this is useful (and I'm not sure it is), then
I'm not so sure about using varobj for this purpose. Varobj would be a lot
busier place to do this sort of thing. It can be done, but I wouldn't do
it this way myself (but the maintainers may feel differently).
> Btw, are there currently any programs using the GDB/MI interface
> (except for cgdb)?
Yes, there are two projects of which I am aware that use MI. Apple's MacOS
X development tools use it (although they have greatly hacked at it and
CVS head is now rapidly diverging from their sources) and Eclipse uses it
(http://www.eclipse.org).
Here are some comments on the code, which is shaping up quite nicely!
In mi_cmd_symbols_locate, you're outputting info on one particular
variable; in mi_cmd_symbol_list_symbols, you're doing for a bunch of them.
I think that print_symbol_info should use tuples instead of lists. This
way, mi_cmd_symbol_list_symbols would output a list of tuples, which I
think is the proper paradigm. mi_cmd_symbols_locate would then simply
output a tuple, which is still correct.
Also the error handling in these functions does not match the way other MI
commands handler errors. Almost all of the commands output the function
name along with the error, and in a few places, you've done that. I would
expand that to all error messages in your code.
I could say something about error() vs mi_error_message, but
mi_error_message isn't public yet, so it's not worth mentioning. [IMO,
error() is evil, and MI has it's own way of dealing with it, but your
hands are tied right now. (I have a patch that would allow other files to
access it, but I haven't submitted it yet.)]
The error message in mi_cmd_symbol_locate doesn't really follow the
"trend": it normally includes the whole command, i.e.,
"mi_cmd_symbol_locate: Usage: -symbol-locate symbol". This happens in a
few other places, too.
You should use a cleanup after you call decode_line_spec so that if
some other GDB function calls error(), the memory for the result will
automatically get deallocated. The normal way this is done
in GDB is something like this:
struct cleanup *old_chain;
sals = decode_line_spec (argv[0], 1);
old_chain = make_cleanup (xfree, sals.sals);
/* do stuff */
do_cleanups (old_chain);
I would double-check that the memory is being freed whenever
decode_line_spec is called (it's missing in one or two places). (Note:
GDB uses xfree(), xmalloc() et al instead of free(), malloc() et al.)
Keith