Re: [RFA] parse_frame_specification (stack.c)

Fernando Nasser
2001-03-05T09:30:00Z

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