Re: [RFC 11/12] entryval: "@entry" in input expressions

[Tom Tromey <tromey@redhat.com>]

>>>>> "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