From mboxrd@z Thu Jan 1 00:00:00 1970 From: Fernando Nasser To: David Taylor Cc: gdb-patches@sourceware.cygnus.com Subject: Re: [RFA] parse_frame_specification (stack.c) Date: Mon, 05 Mar 2001 09:30:00 -0000 Message-id: <3AA3CC5F.9FE84042@redhat.com> References: <200103051707.MAA01373@texas.cygnus.com> X-SW-Source: 2001-03/msg00074.html 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 " > or > "info frame " > > 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