From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4525 invoked by alias); 3 Oct 2011 17:05:42 -0000 Received: (qmail 4517 invoked by uid 22791); 3 Oct 2011 17:05:41 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from lvk-gate.cmc.msu.ru (HELO mail.lvk.cs.msu.su) (212.192.248.233) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 03 Oct 2011 17:05:23 +0000 Received: from mail.lvk.cs.msu.su (localhost [127.0.0.1]) by mail.lvk.cs.msu.su (Postfix) with ESMTP id D5211DC0; Mon, 3 Oct 2011 21:05:18 +0400 (MSK) X-Spam-ASN: Received: from thunder.localnet (h86-62-88-129.ln.rinet.ru [86.62.88.129]) by mail.lvk.cs.msu.su (Postfix) with ESMTPSA id BF72D63F; Mon, 3 Oct 2011 21:05:18 +0400 (MSD) From: Vladimir Prus To: Tom Tromey Subject: Re: [MI RFC] entryval: MI access to entry values [Re: [RFC 06/12] entryval: Display @entry parameters in bt full] Date: Mon, 03 Oct 2011 17:05:00 -0000 User-Agent: KMail/1.13.6 (Linux/2.6.38-11-generic-pae; KDE/4.6.2; i686; ; ) Cc: Jan Kratochvil , gdb-patches@sourceware.org References: <20110718201852.GG30496@host1.jankratochvil.net> <20110902170745.GA22738@host1.jankratochvil.net> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-6" Content-Transfer-Encoding: 7bit Message-Id: <201110032105.17607.vladimir@codesourcery.com> X-AV-Checked: ClamAV using ClamSMTP 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/msg00028.txt.bz2 On Monday, October 03, 2011 20:57:01 Tom Tromey wrote: > >>>>> "Jan" == Jan Kratochvil writes: > Jan> For (2) and (3) for FEs with proper parser an additional result > Jan> should be ignored correctly. For FEs with some ugly manual > Jan> matching I also do not think it should be a problem as FEs are > Jan> usually used for -O0 -g code debugging while entry values are > Jan> present only in -O2 -g code. > > For the record, I think we should not concern ourselves at all with such > MI consumers, if any exist. MI has flaws, but this isn't among them; we > should expect consumers to reliably ignore new fields. 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. -- Vladimir Prus CodeSourcery / Mentor Graphics +7 (812) 677-68-40