From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10420 invoked by alias); 10 Oct 2011 16:09:16 -0000 Received: (qmail 10411 invoked by uid 22791); 10 Oct 2011 16:09:15 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from smtp.nokia.com (HELO mgw-sa01.nokia.com) (147.243.1.47) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 10 Oct 2011 16:09:00 +0000 Received: from gar.localnet (berwst16747.europe.nokia.com [172.25.167.47]) by mgw-sa01.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p9AG8wYa026682 for ; Mon, 10 Oct 2011 19:08:58 +0300 From: =?iso-8859-1?q?Andr=E9_P=F6nitz?= To: gdb-patches@sourceware.org Subject: Re: [MI RFC] entryval: MI access to entry values [Re: [RFC 06/12] entryval: Display @entry parameters in bt full] Date: Mon, 10 Oct 2011 16:09:00 -0000 User-Agent: KMail/1.13.5 (Linux/2.6.35-30-generic; KDE/4.5.5; i686; ; ) References: <20110718201852.GG30496@host1.jankratochvil.net> <201110032105.17607.vladimir@codesourcery.com> <20111003174320.GA6944@host1.jankratochvil.net> In-Reply-To: <20111003174320.GA6944@host1.jankratochvil.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201110101808.58127.andre.poenitz@nokia.com> X-Nokia-AV: Clean 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: 2011-10/txt/msg00275.txt.bz2 On Monday 03 October 2011 19:43:20 ext Jan Kratochvil wrote: > On Mon, 03 Oct 2011 19:05:17 +0200, Vladimir Prus wrote: > > I presume the question is how important those those @entry values. If this > > is something that would cause user a big grief if not shown, we might just > > show them in format consistent with current frontends. If that's something > > nice, but not essential, than maybe 2/3 are better options. > > I would like to restate that primarily I do not know a case when @entry values > are relevant for FEs and therefore for MI. FEs typically rebuild the inferior > for debugging with -O0 -g and therefore @entry values are not present at all. At least in "my" case libraries loaded by the inferior are often compiled with -O2 -g, and stepping through that code is regularly done by users. I still think it would have been nice to have a clean separation of the data into individual "channels" on the gdb side, especially because this is new functionality, but then, that's easily done on the FE side, too. In any case, thank you for implementing the feature. It's much appreciated. Andre'