This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFC 11/12] entryval: "@entry" in input expressions
- From: Tom Tromey <tromey at redhat dot com>
- To: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Tue, 19 Jul 2011 10:19:47 -0600
- Subject: Re: [RFC 11/12] entryval: "@entry" in input expressions
- References: <20110718202410.GL30496@host1.jankratochvil.net>
>>>>> "Jan" == Jan Kratochvil <jan.kratochvil@redhat.com> writes:
Jan> it would be good if one can also:
Jan> (gdb) print refparam@entry
Jan> $1 = 5
Jan> I am not sure if the entry values should be really indicated by the @entry
Jan> suffix. Also as @entry values are not not_lval it may be enough to display
Jan> them either by `bt full' and `info args' or even by some new command:
Jan> (gdb) entryval param
Jan> #1 = 5
It is better for it to be part of expression parsing, because then the
values can be easily used in breakpoint conditions.
Jan> Also the @entry means the `@' operator and "entry" identifier to be
Jan> overloaded. This way each supported GDB language needs its own *.y
Jan> patch. I will implement some others - specifically Fortran - if
Jan> this syntax gets agreed upon. It means that formerly valid @entry
Jan> meant repeat left expression by the number of times stored in a
Jan> variable named `entry' changes meaning but I do not think it is a
Jan> problem.
I think this approach is ok.
There is already a special case for address spaces in c-exp.y.
Jan> There is some risk of a clash with Koening operator parsing but I
Jan> do not think this patch has any problem with it.
If you are referring to the use of "@" in comments in the Koening code,
that is a placeholder for a generic operator (IIRC the C++ standard uses
this convention); there is no C++ operator actually named "@". So,
there is no risk of clash here.
Tom