From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25404 invoked by alias); 18 Dec 2006 08:15:10 -0000 Received: (qmail 25344 invoked by uid 22791); 18 Dec 2006 08:15:07 -0000 X-Spam-Check-By: sourceware.org Received: from viper.snap.net.nz (HELO viper.snap.net.nz) (202.37.101.8) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 18 Dec 2006 08:14:52 +0000 Received: from kahikatea.snap.net.nz (p202-124-120-4.snap.net.nz [202.124.120.4]) by viper.snap.net.nz (Postfix) with ESMTP id EB67D3D8D78; Mon, 18 Dec 2006 21:16:13 +1300 (NZDT) Received: by kahikatea.snap.net.nz (Postfix, from userid 500) id C22A0BE456; Mon, 18 Dec 2006 21:10:12 +1300 (NZDT) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17798.19683.251190.740216@kahikatea.snap.net.nz> Date: Mon, 18 Dec 2006 08:15:00 -0000 To: Vladimir Prus Cc: gdb-patches@sources.redhat.com Subject: Re: RFC: MI - Detecting change of string contents with variable objects In-Reply-To: References: <17797.65268.689590.797944@kahikatea.snap.net.nz> X-Mailer: VM 7.19 under Emacs 22.0.91.19 X-IsSubscribed: yes 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/msg00233.txt.bz2 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