This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [RFA] parse_frame_specification (stack.c)
- To: Fernando Nasser <fnasser at redhat dot com>
- Subject: Re: [RFA] parse_frame_specification (stack.c)
- From: David Taylor <taylor at cygnus dot com>
- Date: Mon, 05 Mar 2001 13:30:34 -0500
- cc: gdb-patches at sourceware dot cygnus dot com
Date: Mon, 05 Mar 2001 12:26:55 -0500
From: Fernando Nasser <fnasser@redhat.com>
David,
The real problem here is that there is an ambiguity in this command
argument specification. If a frame is specified as an address, it
should be proceeded by a "*" as we do in the break command.
It seems that problems like this have been encountered before. here is
the comment in the code that refers to s similar situation:
I saw that comment; and, by the way, it isn't a new comment -- it was
put into the code in Jan 1994 -- over 7 years ago. I wasn't about to
change the specification for such an entrenched item without there
first being discussion on gdb about it.
Regardless of the outcome of the discussion (assuming there is one) on
whether to change the interface to the frame/info frame commands, I'd
like to get this bug fix committed.
To solve
that, we need a new syntax for a specifying a frame by address.
I think the cleanest syntax is $frame(0x45) ($frame(0x23,0x45) for
two args, etc.), but people might think that is too much typing,
so I guess *0x23,0x45 would be a possible alternative (commas
really should be used instead of spaces to delimit; using spaces
normally works in an expression). */
I don't object to the $frame syntax on grounds of too much typing, but
rather because of what I think it would do to the expression
evaluation code -- you'd have $frame(...) where it has the syntax of a
builtin variable $frame, but it isn't a variable, and it has the
syntax of a function call (...), but it isn't a function call...
Bleh! Extreme bleh!
Maybe we should start requiring the * for addresses and if not assuming
it is a stack level (small integer as you say) and update the manual
accordingly.
My initial reaction would be to favor this change (though I might
change my mind after I think about it more).
I am not going to implement it, though, unless there is consensus that
such a change would be a good thing.
Would you like to lead the discussion?
If I understand your proposal:
123 -- integer
*123 -- address
foo(123) -- call function foo with argument 123, treat the result as
an integer
*foo(123) -- call function foo with argument 123, treat the result as
a pointer and convert it to an address
123,*456,789,*1011 -- integer,address,integer,address
Fernando
David