This is the mail archive of the
mailing list for the GDB project.
Re: RFC: MI - Detecting change of string contents with variable objects
- From: Vladimir Prus <ghost at cs dot msu dot su>
- To: Nick Roberts <nickrob at snap dot net dot nz>, gdb-patches at sources dot redhat dot com
- Date: Mon, 18 Dec 2006 10:01:18 +0300
- Subject: Re: RFC: MI - Detecting change of string contents with variable objects
- References: <firstname.lastname@example.org>
Nick Roberts wrote:
> This post follows on from a thread earlier this month on the GDB mailing
> list called "memory address ranges (-var-create)"
It looks like that thread did not reach a conclusion, though....
> Currently variable objects treat strings as pointers so -var-update only
> detects a change of address or, if the child is created, when the first
> character changes. The patch below detects when the contents change which
> more useful. I've only tested it for C, but I guess it could work for
> languages that variable objects handle (C++, Java). The function
> value_get_value gets both the address and string value but it's probably
> better to just get the string value directly.
I think this is probably a wrong thing to do in MI. Yes, this helps with
char*, but char* happens to be not so important in C++ -- modern code
mostly uses std::string (or QString, or gtkmm::ustring, or whatever). This
patch does not help with those, for the frontend is required to contain
special code to handle string classes. As as soon as it has such special
code, handling char* can be done in frontend as well.
In fact, it looks like your patch only changes the behaviour for C --
if (variable_language (var) == vlang_c &&
but I think we need to avoid special-casing C while not solving any problems
with C++. You mentioned that Insight handles char* just fine -- using
current MI code. What approach is take there?
On technical points:
1. Your value_get_value has no comments at all.
2. I don't see 'string_value' being freed in 'free_variable'