This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [MI RFC] entryval: MI access to entry values [Re: [RFC 06/12] entryval: Display @entry parameters in bt full]
- From: Vladimir Prus <vladimir at codesourcery dot com>
- To: Tom Tromey <tromey at redhat dot com>
- Cc: Jan Kratochvil <jan dot kratochvil at redhat dot com>, gdb-patches at sourceware dot org
- Date: Mon, 3 Oct 2011 21:05:17 +0400
- Subject: Re: [MI RFC] entryval: MI access to entry values [Re: [RFC 06/12] entryval: Display @entry parameters in bt full]
- References: <20110718201852.GG30496@host1.jankratochvil.net> <20110902170745.GA22738@host1.jankratochvil.net> <m3y5x2t3mq.fsf@fleche.redhat.com>
On Monday, October 03, 2011 20:57:01 Tom Tromey wrote:
> >>>>> "Jan" == Jan Kratochvil <jan.kratochvil@redhat.com> 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