Re: [PATCH] Handle ObjC OPS in eval.c

[Michael Snyder <msnyder@redhat.com>]

Adam Fedor wrote:
> 
> 2003-01-02  Adam Fedor  <fedor@gnu.org>
> 
>         * Makefile.in (eval.o): Add $(objc_lang_h)
>         * eval.c (evaluate_subexp_standard): Handle ObjC ops.
>         * valops.c (find_function_addr): Make non-static.
>         * value.h (find_function_addr): Declare.

Adam, this is OK in principal, assuming that the objc code
such as value_nsstring is being unconditionally built now.
A few remarks:

>
> +       /* Verify target responds to method selector. This logic needs
> +        * work: not sure of GNU variant's name.  Must also account for
> +        * new (NSObject) and old (Object) worlds
> +        */
> +
> +       if (1)

Is there a reason for this if(1)?

> +
> +#ifdef GDB_TARGET_IS_HPPA
> +           CORE_ADDR tmp;
> +           /* code and comment lifted from hppa-tdep.c -- unfortunately
> +              there is no builtin function to do this for me. */
> +           /* If bit 30 (counting from the left) is on, then addr is the
> +              address of the PLT entry for this function, not the address
> +              of the function itself.  Bit 31 has meaning too, but only
> +              for MPE.  */
> +           if (addr & 0x2)
> +             addr = (CORE_ADDR) read_memory_unsigned_integer (addr & ~0x3, 4);
> +           if (tmp = skip_trampoline_code (addr, 0))
> +             addr = tmp;       /* in case of trampoline code */
> +#endif

Ifdef gdb_target is a big no-no.  Can you use gdbarch for this?


> +       if (method)
> +         {
> +           struct block *b;
> +           CORE_ADDR funaddr;
> +           struct type *value_type;
> +
> +           funaddr = find_function_addr (method, &value_type);

This is surely not the best way to do this.  You can get 
the address and the type from the symbol.  If op_funcall
doesn't need to call it, why does op_objc_msgcall?