Re: [RFA] parse_frame_specification (stack.c)

[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:

        /* If SETUP_ARBITRARY_FRAME is defined, then frame
specifications
           take at least 2 addresses.  It is important to detect this
case
           here so that "frame 100" does not give a confusing error
message
           like "frame specification requires two addresses".  This of
course
           does not solve the "frame 100" problem for machines on which
           a frame specification can be made with one address.  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).  */

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.

Fernando



David Taylor wrote:
> 
> [This is a revision of my previous patch.
> 
> For most processors (specifically, those that use the default identity
> transformations for pointer -> address and address -> pointer), this
> patch is a no op.]
> 
> In gdb, if you say:
> 
>     "frame <small-number>"
> or
>     "info frame <small-number>"
> 
> then you expect to either move up or down some number of frames or to
> get information on the frame having the specified "index".
> 
> But, if for your gdb target, addresses and pointers are different,
> then the current code in parse_frame_specification will treat the
> number as a pointer and convert it to an address.
> 
> So, if you have a Harvard architecture processor where a pointer of 0
> (say) corresponds to a text address of 0x2000000 and a data address of
> 0x1000000, and you say
> 
>     frame 0
> 
> then gdb will try to move to frame 0x1000000.
> 
> Assuming you don't have that many frames, it will then try to create a
> frame at address 0x1000000.  Which, in my case, will generate an
> error...
> 
> This fixes it so that
> 
>     frame 0
> 
> will do the right thing on such configurations.
> 
> ChangeLog entry:
> 
>         * stack.c (parse_frame_specification): For one argument case,
>         handle the situation where the argument is an integer, not an
>         address -- arguably the most common case.  This matters on
>         targets where pointers and addresses are different.
> 
> Index: stack.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/stack.c,v
> retrieving revision 1.12
> diff -c -r1.12 stack.c
> *** stack.c     2001/02/10 12:01:11     1.12
> --- stack.c     2001/03/05 16:47:52
> ***************
> *** 704,709 ****
> --- 704,710 ----
>     int numargs = 0;
>   #define       MAXARGS 4
>     CORE_ADDR args[MAXARGS];
> +   int level;
> 
>     if (frame_exp)
>       {
> ***************
> *** 723,730 ****
>           addr_string = savestring (frame_exp, p - frame_exp);
> 
>           {
>             tmp_cleanup = make_cleanup (xfree, addr_string);
> !           args[numargs++] = parse_and_eval_address (addr_string);
>             do_cleanups (tmp_cleanup);
>           }
> 
> --- 724,738 ----
>           addr_string = savestring (frame_exp, p - frame_exp);
> 
>           {
> +           value_ptr vp;
> +
>             tmp_cleanup = make_cleanup (xfree, addr_string);
> !
> !           vp = parse_and_eval (addr_string);
> !           if (numargs == 0)
> !             level = value_as_long (vp);
> !
> !           args[numargs++] = value_as_pointer (vp);
>             do_cleanups (tmp_cleanup);
>           }
> 
> ***************
> *** 744,750 ****
>         /* NOTREACHED */
>       case 1:
>         {
> -       int level = args[0];
>         struct frame_info *fid =
>         find_relative_frame (get_current_frame (), &level);
>         struct frame_info *tfid;
> --- 752,757 ----

-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9