From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15572 invoked by alias); 19 Mar 2010 02:12:46 -0000 Received: (qmail 15563 invoked by uid 22791); 19 Mar 2010 02:12:45 -0000 X-SWARE-Spam-Status: No, hits=-2.6 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from ey-out-1920.google.com (HELO ey-out-1920.google.com) (74.125.78.146) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 19 Mar 2010 02:12:41 +0000 Received: by ey-out-1920.google.com with SMTP id 26so222297eyw.42 for ; Thu, 18 Mar 2010 19:12:38 -0700 (PDT) Received: by 10.213.8.26 with SMTP id f26mr37981ebf.14.1268964758395; Thu, 18 Mar 2010 19:12:38 -0700 (PDT) Received: from [172.16.145.14] ([61.164.42.188]) by mx.google.com with ESMTPS id 16sm485737ewy.11.2010.03.18.19.12.35 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 18 Mar 2010 19:12:37 -0700 (PDT) Message-ID: <4BA2DD0A.9030904@gmail.com> Date: Fri, 19 Mar 2010 02:12:00 -0000 From: Asm_gmail User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.19) Gecko/20081209 Thunderbird/2.0.0.19 Mnenhy/0.7.6.0 MIME-Version: 1.0 To: Joel Brobecker CC: gdb@sourceware.org Subject: Re: gdb-7.1 - last call before release (Wed, Mar 17th) References: <20100316161124.GE3844@adacore.com> <4BA03709.6070702@gmail.com> <20100317141208.GJ3844@adacore.com> In-Reply-To: <20100317141208.GJ3844@adacore.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: 2010-03/txt/msg00162.txt.bz2 On 2010-3-17 22:12, Joel Brobecker wrote: >> But it seems the command interpreter is still a little slower than >> the 7.0.1 version. As I have reported this issue in this maillist >> before. >> Sorry I can't compile it with -pg option. see here: >> http://sourceware.org/ml/gdb/2010-03/msg00029.html >> > I don't think that this is a blocking issue, but I would possibly > consider delaying the release while someone investigates. However, > someone has to step up... Otherwise, I am afraid that we're just going > to delay the release without a clear idea of how long the delay might be. > > I'm not going to start the process until later this afternoon (Pacific > time). If someone steps up, then great, we can delay for a day or two > to see what he finds. Otherwise, there's always going to be 7.1.1 or > 7.2... > > Hi, Joel Today, I found that you have released the official 7.1 version. So I download it and build it again( MinGW32). I used it in Codeblocks, and it works fine. But the only issue is: It seems When I'm debugging a dll (it is a Codeblocks' plugin), then I put some watch variables in the watch window. Then I step in the source code, it seems that when the variables were in the current frame, it return the value very fast, like: F:\cb_svn\src\plugins\codecompletion\parser\tokenizer.cpp:644:18273:beg:0x65ed34a3 >>>>>>cb_gdb: > whatis m_LineNumber type = unsigned int >>>>>>cb_gdb: > output m_LineNumber 1>>>>>>cb_gdb: > whatis m_TokenIndex type = unsigned int >>>>>>cb_gdb: > output m_TokenIndex 0>>>>>>cb_gdb: But when the variables was out of the current frame, see the debug log: F:\cb_svn\src\plugins\codecompletion\parser\parserthread.cpp:448:14091:beg:0x65ec27c6 >>>>>>cb_gdb: > whatis m_LineNumber No symbol "m_LineNumber" in current context. >>>>>>cb_gdb: > output m_LineNumber No symbol "m_LineNumber" in current context. >>>>>>cb_gdb: > whatis m_TokenIndex No symbol "m_TokenIndex" in current context. >>>>>>cb_gdb: > output m_TokenIndex No symbol "m_TokenIndex" in current context. >>>>>>cb_gdb: At this time, the command interpreter runs really slow. As I have said that output a wxString value is quite slow, today, I think this is another lag problem, not only the wxString ,but also a build-in type variable. Thanks. asmwarrior (ollydbg from codeblocks forum).