Re: RFC: MI - Detecting change of string contents with variable objects

[Nick Roberts <nickrob@snap.net.nz>]

Vladimir Prus writes:
 > 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....

That's why I've continued it here.

 > > 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
 > > is
 > > more useful.  I've only tested it for C, but I guess it could work for
 > > other
 > > 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. 

You seem to be saying that because it won't work generally for C++ it should
not be made to work for C.

 > In fact, it looks like your patch only changes the behaviour for C --
 > you have:
 > 
 >           if (variable_language (var) == vlang_c &&

Yes, sorry I was trying to say it only currently works for C.

 > but I think we need to avoid special-casing C while not solving any problems
 > with C++. 

I think it's better than nothing.  If you can think of a more general approach
that would be even better.

 >            You mentioned that Insight handles char* just fine -- using
 > current MI code. What approach is take there?

GDB is built into Insight as a single executable, it doesn't rely on
interprocess communication with the frontend.  It compares the displayed string
in the watch expression window with the current value.

 > On technical points:
 > 
 > 1. Your value_get_value has no comments at all.

Its based on c_value_of_variable but this is just a rough sketch.

 > 2. I don't see 'string_value' being freed in 'free_variable'

OK thanks, I hadn't noticed that.

-- 
Nick                                           http://www.inet.net.nz/~nickrob