From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21481 invoked by alias); 11 Jul 2005 09:53:12 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 21446 invoked by uid 22791); 11 Jul 2005 09:53:08 -0000 Received: from viper.snap.net.nz (HELO viper.snap.net.nz) (202.37.101.8) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Mon, 11 Jul 2005 09:53:08 +0000 Received: from farnswood.snap.net.nz (p2-tnt1.snap.net.nz [202.124.110.2]) by viper.snap.net.nz (Postfix) with ESMTP id 6CF4A5E4E52; Mon, 11 Jul 2005 21:52:13 +1200 (NZST) Received: by farnswood.snap.net.nz (Postfix, from userid 501) id B608C62A99; Mon, 11 Jul 2005 10:54:22 +0100 (BST) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17106.16846.134992.221438@farnswood.snap.net.nz> Date: Mon, 11 Jul 2005 09:53:00 -0000 To: Vladimir Prus Cc: gdb@sources.redhat.com Subject: Re: Formatting of function pointer value In-Reply-To: References: <20050708135810.GB17089@nevyn.them.org> <17106.5796.850869.491390@farnswood.snap.net.nz> <17106.10589.435150.575928@farnswood.snap.net.nz> X-SW-Source: 2005-07/txt/msg00106.txt.bz2 > > > Ok, the the only advantage of MI is stable output format. > > > > I've not said that. It also uses variable objects, it aims to be > > asynchronous... > > Could you give more details? Basically, Daniel suggested that I use MI > instead of CLI. I think thats sound advice. If you use CLI for KDevelop (?) and then GDB developers change the CLI output, it will break things for you and you'll have wasted a lot of effort. > I've asked about the reasons why I should, and if possible, I'd like to see > all reasons, with a easy to understand descriptions. I don't think you'll get that. GDB is a voluntary project. You just have to work with what's available (or pay someone). > For example, the term "variable objects" says nothing to me, and it's > description: > > For the implementation of a variable debugger window (locals, watched > expressions, etc.), we are proposing the adaptation of the existing code > used by `Insight'. > > does not sched might light either. I've learnt what I know about variable objects from using Insight, reading the manual and looking at the source code. I still don't understand the asynchronous operation which only works under limited conditions. ... > > > For example, looking at the code that prints function values (what > > > worries me in the first place): > > > > > > fprintf_filtered (stream, "{"); > > > type_print (type, "", stream, -1); > > > fprintf_filtered (stream, "} "); > > > > I don't understand the point of the example. > > The point of the example is that this code seem to be executed both in MI > and CLI modes. So, if '{' is changed to '(', it will equally affect MI and > CLI, which makes me wonder why MI is more stable that CLI. If you are going to generalise the whole of MI and CLI from this one very small example, then I can see that it would make you wonder why MI is more stable that CLI > As you can see from my other post, the formatting of value is indeed the > same for MI and CLI. Yes, but you can easily parse the MI output and replace '{' with whatever you want. Nick