From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1497 invoked by alias); 7 Feb 2003 18:31:10 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 1489 invoked from network); 7 Feb 2003 18:31:09 -0000 Received: from unknown (HELO external1.doc.com) (63.119.183.65) by 172.16.49.205 with SMTP; 7 Feb 2003 18:31:09 -0000 Received: (qmail 30360 invoked from network); 7 Feb 2003 18:30:52 -0000 Received: from cpe-24-221-209-215.co.sprintbbd.net (HELO doc.com) (24.221.209.215) by external1 with SMTP; 7 Feb 2003 18:30:52 -0000 Message-ID: <3E43FB6A.3030505@doc.com> Date: Fri, 07 Feb 2003 18:31:00 -0000 From: Adam Fedor User-Agent: Mozilla/5.0 (X11; U; Linux ppc; en-US; rv:1.1) Gecko/20020905 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Snyder CC: GDB Patches Subject: Re: [PATCH] Handle ObjC OPS in eval.c References: <3E15F21B.6010101@doc.com> <3E39E887.AB98ECA4@redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-02/txt/msg00239.txt.bz2 Michael Snyder wrote: > Adam Fedor wrote: > >>2003-01-02 Adam Fedor >> >> * 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.