From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11991 invoked by alias); 23 Jan 2007 17:20:24 -0000 Received: (qmail 11983 invoked by uid 22791); 23 Jan 2007 17:20:23 -0000 X-Spam-Check-By: sourceware.org Received: from vir-del-03.spheriq.net (HELO vir-del-03.spheriq.net) (194.50.41.42) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 23 Jan 2007 17:20:15 +0000 Received: from vir-out-02.spheriq.net ([194.50.41.31]) by vir-del-03.spheriq.net with ESMTP id l0NGdlQ2032207 for ; Tue, 23 Jan 2007 16:39:47 GMT Received: from vir-cus-01.spheriq.net (vir-cus-01.spheriq.net [194.50.41.85]) by vir-out-02.spheriq.net with ESMTP id l0NGdlVA032043 for ; Tue, 23 Jan 2007 16:39:47 GMT Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35]) by vir-cus-01.spheriq.net with ESMTP id l0NGdidT017375 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 23 Jan 2007 16:39:46 GMT Received: from zeta.dmz-eu.st.com (ns2.st.com [164.129.230.9]) by beta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 792E9DA49 for ; Tue, 23 Jan 2007 16:39:44 +0000 (GMT) Received: from mail1.cro.st.com (mail1.cro.st.com [164.129.40.131]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 14204476EB for ; Tue, 23 Jan 2007 16:39:41 +0000 (GMT) Received: from [164.129.44.95] (crx595.cro.st.com [164.129.44.95]) by mail1.cro.st.com (MOS 3.5.8-GR) with ESMTP id CJM34657 (AUTH "denis pilat"); Tue, 23 Jan 2007 17:39:38 +0100 (CET) Message-ID: <45B63A49.4010609@st.com> Date: Tue, 23 Jan 2007 17:20:00 -0000 From: Denis PILAT User-Agent: Thunderbird 1.5.0.9 (X11/20061206) MIME-Version: 1.0 To: Denis PILAT , gdb-patches Subject: Re: [RFC] varobj deletion after the binary has changed References: <45B60056.6030704@st.com> <20070123124457.GA1600@nevyn.them.org> In-Reply-To: <20070123124457.GA1600@nevyn.them.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: 2007-01/txt/msg00482.txt.bz2 Daniel Jacobowitz wrote: > On Tue, Jan 23, 2007 at 01:32:22PM +0100, Denis PILAT wrote: > >> Hi, >> >> We have a bug in one of our gdb target, when the binary changed while >> beeing debugged it appears that some of our varobj refers to invalid >> symbols or type. >> >> I propose a patch that delete all varobj when symbols are reloaded. May >> be there is a better place to do that but I think we must do that >> somewhere, don't you ? >> > > The right thing to do is probably to figure out where the > invalid references come from and fix them - probably by re-evaluating > expressions at the next -var-update. Deleting things behind the front > end's back is a bad policy. > > > Deleting all is a little bit radical, I can understand that. Re-evaluating expression would give the expected thing for globale variables, but for varobj that has been set on local variable (so within a "valid_block"), it should have side effects: the evaluation of the expression might tied the varobj to a variable different than the one the user originally decided. I propose to distinguish 2 cases - varobj on global variable (valid_block == null) must have their expression re-evaluated. - other one must be put in a kind of invalid state that will gives "in_scope="false" to the user. This last point will involve a new field in varobj structure, I haven't seen something to mark varobj as invalid. Denis