This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH]: Add expected type to hand_function_call




Elena Zannoni wrote:
Adam Fedor writes:
> > > Elena Zannoni wrote:
> > Adam Fedor writes:
> > > This patch adds a parameter to hand_function_call that can be used to > > > check the type of the function return. This is used often with > > > Objective-C as this information is known by the runtime and can be used > > > to check the validity of the function.
> > > > > > 2002-11-24 Adam Fedor <fedor at gnu dot org>
> > > > > > * valops.c (find_function_addr): Make non-static.
> > > (hand_function_call): Add expect_type arg, use it to check
> > > return type of function (updated by Klee Dienes <kdienes at apple dot com>).
> > > (call_function_by_hand): Update for change in hand_function_call.
> > > (call_function_by_hand_expecting_type): New function.
> > > * value.h (find_function_addr,
> > > call_function_by_hand_expecting_type): Declare.
> > > > > > Index: valops.c
> > > ===================================================================
> > > RCS file: /cvs/src/src/gdb/valops.c,v
> > > retrieving revision 1.79
> > > diff -u -p -r1.79 valops.c
> > > --- valops.c 7 Nov 2002 02:45:27 -0000 1.79
> > > +++ valops.c 25 Nov 2002 02:50:17 -0000
> > > @@ -48,7 +48,6 @@ extern int overload_debug;
> > > static int typecmp (int staticp, int varargs, int nargs,
> > > struct field t1[], struct value *t2[]);
> > > > > > -static CORE_ADDR find_function_addr (struct value *, struct type **);
> > > static struct value *value_arg_coerce (struct value *, struct type *, int);
> > > > > > > > > @@ -1228,7 +1227,7 @@ value_arg_coerce (struct value *arg, str
> > > /* Determine a function's address and its return type from its value.
> > > Calls error() if the function is not valid for calling. */
> > > > > > -static CORE_ADDR
> > > +CORE_ADDR
> > > find_function_addr (struct value *function, struct type **retval_type)
> > > {
> > > register struct type *ftype = check_typedef (VALUE_TYPE (function));
> > > @@ -1296,7 +1295,8 @@ find_function_addr (struct value *functi
> > > ARGS is modified to contain coerced values. */
> > > > > > static struct value *
> > > -hand_function_call (struct value *function, int nargs, struct value **args)
> > > +hand_function_call (struct value *function, struct type *expect_type,
> > > + int nargs, struct value **args)
> > > {
> > > register CORE_ADDR sp;
> > > register int i;
> > > @@ -1342,6 +1342,17 @@ hand_function_call (struct value *functi
> > > if (!target_has_execution)
> > > noprocess ();
> > > > > > + funaddr = find_function_addr (function, &value_type);
> > > + CHECK_TYPEDEF (value_type);
> > > +
> > > + if ((value_type == NULL) || (TYPE_CODE (value_type) == TYPE_CODE_ERROR))
> > > + value_type = expect_type;
> > > +
> > > + if ((value_type == NULL) || (TYPE_CODE (value_type) == TYPE_CODE_ERROR))
> > > + error ("Unable to call function at 0x%lx: no return type information available.\n"
> > > + "To call this function anyway, you can cast the return type explicitly (e.g. 'print (float) fabs (3.0)')",
> > > + (unsigned long) funaddr);
> > > +
> > > > Could this code be moved into the new function? This way you could leave
> > hand_function_call alone, and just have 2 wrappers call_function_by_hand and
> > call_function_by_hand_expecting_type.
> > > > It's possible, but doing that would probably make it more contrived, and > I would still have to change hand_function_call to pass in the > value_type. Really, if I just remove the error message for NULL > value_type, the entire change just consists of one if statement:
> > if ((value_type == NULL) || (TYPE_CODE (value_type) == TYPE_CODE_ERROR))
> value_type = expect_type;
> > Which is pretty benign.
>


Oh wait. Ignore my comments. I went and reread the old thread when
this was submitted by apple.  There was some agreement that the error
message was a good thing. So it should stay.

Also, the new behavior should be documented.

Did you submit the corresponding change to the eval.c file? I don't
see it.


Well, I have to admit, after looking at this in more detail, I can't get the patch to work any more (and after a lot of debugging, I can't see how it worked in the first place:-( ). But since it's not really critical to getting Objective-C working, I haven't spent much time on it. I'd rather concentrate on the other parts and save this one until later.




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]