Re: [RFA] parse_frame_specification (stack.c)

[David Taylor <taylor@cygnus.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