This is the mail archive of the 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: MI - Detecting change of string contents with variable objects

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
> 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. 

In fact, it looks like your patch only changes the behaviour for C --
you have:

          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'

- Volodya

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