From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Taylor To: Fernando Nasser Cc: gdb-patches@sourceware.cygnus.com Subject: Re: [RFA] parse_frame_specification (stack.c) Date: Mon, 05 Mar 2001 10:31:00 -0000 Message-id: <200103051830.NAA01396@texas.cygnus.com> X-SW-Source: 2001-03/msg00075.html Date: Mon, 05 Mar 2001 12:26:55 -0500 From: Fernando Nasser 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