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

[Adam Fedor <fedor@doc.com>]

Michael Snyder wrote:
> 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)?
> 
> 

Not really. I was trying to maintain a certain compatibility with Apple 
source (indentation), but that's probably too much trouble.

>>+
>>+#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?
> 
> 

I tried looking at gdbarch, but it's a bit complicated for me so I 
couldn't understand much. I saw that OP_FUNCALL was using

if (hp_som_som_object_present)

for a similar type of check. Is that ok to use?


> 
>>+       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?

It seems to me that OP_FUNCALL is doing about the same thing (without 
having to go through a dispatcher to get the actual function). But 
perhaps I'm missing something. Is there a newer way to do this?


-- 
Adam Fedor, Digital Optics Corp.      | I'm glad I hate spinach, because
http://www.doc.com                    | if I didn't, I'd eat it, and you
                                       | know how I hate the stuff.