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: [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



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