From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16791 invoked by alias); 23 May 2008 16:46:42 -0000 Received: (qmail 16741 invoked by uid 22791); 23 May 2008 16:46:42 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 23 May 2008 16:46:24 +0000 Received: (qmail 31326 invoked from network); 23 May 2008 16:46:22 -0000 Received: from unknown (HELO localhost) (vladimir@127.0.0.2) by mail.codesourcery.com with ESMTPA; 23 May 2008 16:46:22 -0000 From: Vladimir Prus To: Vincent Benony Subject: Re: GDB C plugin system, and STL container viewer as an example Date: Fri, 23 May 2008 20:46:00 -0000 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) Cc: gdb-patches@sources.redhat.com References: <1211535909.8253.16.camel@bsr-desktop> <1211560307.6621.26.camel@bsr-desktop> In-Reply-To: <1211560307.6621.26.camel@bsr-desktop> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200805232046.20299.vladimir@codesourcery.com> 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: 2008-05/txt/msg00686.txt.bz2 On Friday 23 May 2008 20:31:47 Vincent Benony wrote: > Le vendredi 23 mai 2008 =C3=A0 18:43 +0400, Vladimir Prus a =C3=A9crit : >=20 > >=20 > > What happens for vector< vector >? It does not seem like you handl= e the > > inner items. > >=20 >=20 > I do, my plugin can handle this kind of STL type imbrication. Can you clarify how? Suppose I have varobj V, of vector > type. V has two children, V.0 and V.1, which are both empty. The first child is resized and -var-update V is send to GDB. If I read your patch correctly, then you'll only check V itself -- I don't see where the V's children will be updated. Can you point me at the code. > > >=20 > > > It seems to work well into KDevelop=20 > >=20 > > Strange, I don't know any codepath in KDevelop 3.5 that could possible = handle this. > > Which version did you try with? > >=20 >=20 > 3.5.1 >=20 > indeed, it seems there is a problem with KDevelop >=20 > If you try a very simple project like that : >=20 > #include >=20 > int main(int, char **) > { > std::vector v; > =EF=BB=BFv.push_back(1); > =EF=BB=BFv.push_back(2); > =EF=BB=BFv.push_back(3); > =EF=BB=BFv.push_back(4); > v[2]=3D5; > *(v.begin()) =3D 6; > return 0; > } >=20 > in KDevelop, place a breakpoint on the "v.push_back(2);" line, add a > watch expression to 'v'. >=20 > Expand local and watch views of 'v' variable. Then step line by line, > and you'll see that 'watch' part is correctly updated,=20 This is because all versions of GDB except for CVS HEAD is uncapable of pro= perly supporting watches via MI interface. As result, KDevelop has to reevaluate = watches at each step, which probably leads to this "workiness" > whereas 'local'=20 > part is not. >=20 > Could it be fixed by something in my GDB patch, or is it a KDevelop > problem, ie does KDevelop assumes that an array never changes its size ? Current version of MI assumes so -- there's no way to say that the number of children has changed, and nothing says that if a variable object is reported as changed, the frontend is required to re-get the list of children.=20 - Volodya