From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24997 invoked by alias); 18 Dec 2006 07:01:54 -0000 Received: (qmail 24988 invoked by uid 22791); 18 Dec 2006 07:01:53 -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 07:01:49 +0000 Received: from Debian-exim by zigzag.lvk.cs.msu.su with spam-scanned (Exim 4.50) id 1GwCVM-0008SY-CO for gdb-patches@sources.redhat.com; Mon, 18 Dec 2006 10:01:45 +0300 Received: from localhost ([127.0.0.1] helo=ip6-localhost) by zigzag.lvk.cs.msu.su with esmtp (Exim 4.50) id 1GwCV8-0008SD-TG; Mon, 18 Dec 2006 10:01:31 +0300 From: Vladimir Prus Subject: Re: RFC: MI - Detecting change of string contents with variable objects To: Nick Roberts , gdb-patches@sources.redhat.com Date: Mon, 18 Dec 2006 07:01:00 -0000 References: <17797.65268.689590.797944@kahikatea.snap.net.nz> User-Agent: KNode/0.10.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit Message-Id: 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/msg00229.txt.bz2 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