From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 807 invoked by alias); 18 Dec 2006 08:36:19 -0000 Received: (qmail 795 invoked by uid 22791); 18 Dec 2006 08:36:19 -0000 X-Spam-Check-By: sourceware.org Received: from zigzag.lvk.cs.msu.su (HELO zigzag.lvk.cs.msu.su) (158.250.17.23) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 18 Dec 2006 08:36:13 +0000 Received: from Debian-exim by zigzag.lvk.cs.msu.su with spam-scanned (Exim 4.50) id 1GwDyj-0002Rn-Ll for gdb-patches@sources.redhat.com; Mon, 18 Dec 2006 11:36:10 +0300 Received: from localhost ([127.0.0.1] helo=ip6-localhost) by zigzag.lvk.cs.msu.su with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1GwDye-0002Ra-6B; Mon, 18 Dec 2006 11:36:04 +0300 From: Vladimir Prus To: Nick Roberts Subject: Re: RFC: MI - Detecting change of string contents with variable objects Date: Mon, 18 Dec 2006 08:36:00 -0000 User-Agent: KMail/1.9.1 Cc: gdb-patches@sources.redhat.com References: <17797.65268.689590.797944@kahikatea.snap.net.nz> <17798.19683.251190.740216@kahikatea.snap.net.nz> In-Reply-To: <17798.19683.251190.740216@kahikatea.snap.net.nz> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200612181136.02429.ghost@cs.msu.su> Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-12/txt/msg00234.txt.bz2 On Monday 18 December 2006 11:10, Nick Roberts wrote: > > > 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. Right, because it would be bad to have, in any given frontend, two different solutions for C and 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. First of all, what's the problem? The problem as I see is that for some types, default comparison rules used by MI is not appropriate. This problem can be solved either by: 1. Having frontend grab the value on each step and do the comparison itself. 2. Adding some 'comparison customization' to MI. (2) might work like this: -var-set-comparator V "strcmp($a, $b) == 0" then MI can set "$a" and "$b" to old and new value, and evaluate this expression. I'm not sure if (1) or (2) is better. (2) is slightly easier for frontend and it *might* reduce the traffic between gdb and frontend. But (2) has a serious problem -- for std::wstring and QString, frontend has to read the data itself to present it to the user, since -var-evaluate-expression returns nothing interesting for std::wstring and QString. This suggests that we need: -var-set-format-expression "................." and the ellipsis part is a big problem. For QString, KDevelop does the following: $kdev_d=%1.d $kdev_s=$kdev_d.size $kdev_s= ($kdev_s > 0)? ($kdev_s > 100 ? 200 : 2*$kdev_s) : 0 ($kdev_s>0) ? (*((char*)&$kdev_d.unicode[0])@$kdev_s) : \"\"" and for complex data structures things can get out of control -- I don't fancy writing programs in gdb script language. Imagine the most complex case: std::map. Should variable object detect changes in objects of that kind by looking at all contained elements and comparing them? Should formatting of std::map be done in gdb, or in frontend? If it's better be done in gdb, then I think we'd need Python binding, so that you can do: define_python_function kdevelop_format_std_map ........... -var-set-format-expression V "kdevelop_format_std_map($a)" or something like that. But as I say, I don't yet sure such formatting should happen in gdb. > > 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. Ah, ok. - Volodya