From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10786 invoked by alias); 31 Jul 2007 10:29:15 -0000 Received: (qmail 10778 invoked by uid 22791); 31 Jul 2007 10:29:14 -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; Tue, 31 Jul 2007 10:29:11 +0000 Received: from kahikatea.snap.net.nz (73.63.255.123.dynamic.snap.net.nz [123.255.63.73]) by viper.snap.net.nz (Postfix) with ESMTP id CDCCE3DA0B9; Tue, 31 Jul 2007 22:29:08 +1200 (NZST) Received: by kahikatea.snap.net.nz (Postfix, from userid 1000) id C4B838FC6D; Tue, 31 Jul 2007 22:29:02 +1200 (NZST) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18095.3821.812493.749018@kahikatea.snap.net.nz> Date: Tue, 31 Jul 2007 10:39:00 -0000 To: =?iso-8859-1?q?Andr=E9_P=F6nitz?= Cc: gdb-patches@sourceware.org Subject: Re: Type information in -data-evaluate-expression In-Reply-To: <200707311113.15152.apoenitz@trolltech.com> References: <200707301540.59361.apoenitz@trolltech.com> <200707310922.14919.apoenitz@trolltech.com> <18094.60992.646812.570359@kahikatea.snap.net.nz> <200707311113.15152.apoenitz@trolltech.com> X-Mailer: VM 7.19 under Emacs 22.1.50.3 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-07/txt/msg00327.txt.bz2 > Ok, I get this now. > > But that's nice. I am running with "set unwindonsignal on" anyway as my > "custom data dumpers" tend to produce (expectedly so...) segmentation > faults when being thrown on uninitialized data structures. > > So this really does not hurt. I can even call -data-evaluate-expression > abort() directly and am still able to continue debugging. I guess other unpleasant things could happen, like variables changing value. >... > Uh... I see a possible way to improve things, but this would be certainly > _way_ more intrusive than the proposed two-line addition we are currently > discussing so extensively ;-) I'm discussing other, possibly better, alternatives. I guess there's no harm in your change as long as you provide a test for the testsuite, documentation, maintenance etc... but a global maintainer approves the change anyway. > The idea is to run custom code in certain cases, e.g. when outputting > "type=foo,value=..." fields one would be able to hook in code which gets > passed type information and start address and some kind of stream to > write to and then _I_ could have my code to output e.g. > > value=[{name="length",type="size_t",value="2005",readonly="true"}, > {name="0",type="std::string",value="first item"}, > ... {name="2004",type="std::string",value="two thousand and fifth item}] > > Unfortunately gdb scripts are ... erm... 'a bit' too slow to provide that > functionality for structures containing more than a handful items, but > the idea also works with compiled code injected into the debugged process. > I am doing that currently using dlopen/LoadLibraryA and it "works" (even with > unitialized objects -- it would btw be really nice if _that_ information were > available without going through segfaults...) Such a change is way over my head, but GDB runs on many architectures and I think it would need to be portable. >... > > If execution is at the arrow, the user might place the mouse over the first > > occurrence of i and expect the value 1 to be displayed. However, since > > -data-evaluate-expression evaluates relative to the current line, 10 would > > actually be displayed. > > Right. Living a programmer's life is risky. Computers are lying to you all > the time... [The problem is that s/Computers/Humans/ and > s/programmer's/real/ does not change the truth value at all ;-}] > > [Apart from that: My target group prefers getting tooltips that are > sometimes (or even most of the time) wrong over getting no tooltips at all.] Life _is_ risky but, if possible, I still like to improve the odds. -- Nick http://www.inet.net.nz/~nickrob