This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: RFC: MI - Detecting change of string contents with variable objects
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