From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26918 invoked by alias); 19 May 2007 01:58:09 -0000 Received: (qmail 26882 invoked by uid 22791); 19 May 2007 01:58:07 -0000 X-Spam-Check-By: sourceware.org Received: from hq.tensilica.com (HELO mailapp.tensilica.com) (65.205.227.29) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 19 May 2007 01:58:01 +0000 Received: from localhost ([127.0.0.1]) by mailapp.tensilica.com with esmtp (Exim 4.34) id 1HpECk-0007EK-0B; Fri, 18 May 2007 18:57:58 -0700 Received: from mailapp.tensilica.com ([127.0.0.1]) by localhost (mailapp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27601-03; Fri, 18 May 2007 18:57:57 -0700 (PDT) Received: from maxim_fc5.hq.tensilica.com ([192.168.11.68]) by mailapp.tensilica.com with esmtp (Exim 4.34) id 1HpECj-0007ED-GY; Fri, 18 May 2007 18:57:57 -0700 Message-ID: <464E59A5.2010208@hq.tensilica.com> Date: Sat, 19 May 2007 01:58:00 -0000 From: Maxim Grigoriev User-Agent: Thunderbird 1.5.0.9 (X11/20070102) MIME-Version: 1.0 To: Maxim Grigoriev CC: gdb@sourceware.org, Pete MacLiesh , Vinay Pandit , Shaiju P , Marc Gauthier , Maxim Grigoriev Subject: Re: Which MI behavior is correct ? References: <464E4C4D.9010709@hq.tensilica.com> In-Reply-To: <464E4C4D.9010709@hq.tensilica.com> Content-Type: multipart/mixed; boundary="------------010000020003090308040706" X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2007-05/txt/msg00082.txt.bz2 This is a multi-part message in MIME format. --------------010000020003090308040706 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-length: 1687 The test case wasn't included: Now, it is. -- Maxim Maxim Grigoriev wrote: > Hello GDB experts, > > I wonder if somebody can help me to understand which > GDB MI behavior is supposed to be correct. > > I've included the test case, the MI commands used, and > the outputs from two debuggers: the native FC5 Linux-X86 > > GNU gdb Red Hat Linux (6.3.0.0-1.134.fc5rh) > > and ours > > GNU gdb 6.5 Xtensa Tools 7.1.0-development > > Our GNU gdb 6.5 is consistent with the top of the FSF tree. > > > PROBLEM DESCRIPTION: > ==================== > > When we hit the breakpoint inside f11() second time: > > In case of 6.3 we have : > > 228^done,changelist=[{name="var3",in_scope="true",type_changed="false"}] > (gdb) > 229^done,changelist=[{name="var4",in_scope="true",type_changed="false"}] > (gdb) > 230^done,value="3" > (gdb) > 231^done,value="2" > (gdb) > > In in case of 6.5+ we have : > > 228^done,changelist=[{name="var3",in_scope="false"}] > (gdb) > 229^done,changelist=[{name="var4",in_scope="false"}] > (gdb) > 230^done,value="2" > (gdb) > 231^done,value="1" > (gdb) > > So "var3" and "var4" are out of scope. > > Our GUI front-end relies on the 6.3-like behavior, which is consistent > with > what we had in our previous releases based on GNU gdb 5.2.1. > > QUESTIONS > ========= > > 1) Is 6.5(+)-style behavior incorrect ? > > If it is correct: > > - Are we supposed to recreate variables each time we enter the > function ? > - Is this efficient ? > > 2) Where can I find a good documentation describing these aspects of > GDB MI ? > All docs I found on the Internet weren't quite helpful. > > Thanks in advance for any of your help. > > -- Maxim > > > > > > --------------010000020003090308040706 Content-Type: text/x-c++src; name="create_var.cxx" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="create_var.cxx" Content-length: 245 #include int f11(int b) { int a; a = b + 1; return a; } int f1(int a) { int b; b = f11(a) + 1; return b; } int main() { int a=1; int b; a = f11(a); a = f11(a); b = f1(a); printf("a,b: %d,%d\n", a, b); return 0; } --------------010000020003090308040706--