From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32012 invoked by alias); 8 Jun 2003 16:43:55 -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 31928 invoked from network); 8 Jun 2003 16:43:53 -0000 Received: from unknown (HELO walton.kettenis.dyndns.org) (62.163.169.212) by sources.redhat.com with SMTP; 8 Jun 2003 16:43:53 -0000 Received: from elgar.kettenis.dyndns.org (elgar.kettenis.dyndns.org [192.168.0.2]) by walton.kettenis.dyndns.org (8.12.6p2/8.12.5) with ESMTP id h58GhiEs000739; Sun, 8 Jun 2003 18:43:44 +0200 (CEST) (envelope-from kettenis@elgar.kettenis.dyndns.org) Received: from elgar.kettenis.dyndns.org (localhost [127.0.0.1]) by elgar.kettenis.dyndns.org (8.12.6p2/8.12.6) with ESMTP id h58Ghi9k048430; Sun, 8 Jun 2003 18:43:44 +0200 (CEST) (envelope-from kettenis@elgar.kettenis.dyndns.org) Received: (from kettenis@localhost) by elgar.kettenis.dyndns.org (8.12.6p2/8.12.6/Submit) id h58GhiTr048427; Sun, 8 Jun 2003 18:43:44 +0200 (CEST) Date: Sun, 08 Jun 2003 16:43:00 -0000 Message-Id: <200306081643.h58GhiTr048427@elgar.kettenis.dyndns.org> From: Mark Kettenis To: ac131313@redhat.com CC: gdb-patches@sources.redhat.com In-reply-to: <3EE0D987.6030207@redhat.com> (message from Andrew Cagney on Fri, 06 Jun 2003 14:12:23 -0400) Subject: Re: [cagney_convert-20030606-branch] Add value to REGISTER_TO_VALUE et.al. References: <3EDE4A9E.70403@redhat.com> <8665nl34ao.fsf@elgar.kettenis.dyndns.org> <3EE0D987.6030207@redhat.com> X-SW-Source: 2003-06/txt/msg00273.txt.bz2 Date: Fri, 06 Jun 2003 14:12:23 -0400 From: Andrew Cagney Mark, I've created the branch: cagney_convert-20030606-branch and committed the attached. It's different from the original in the following ways: - REGISTER_TO_VALUE and VALUE_TO_REGISTER take the full ``struct value'' instead of ``struct type'' and a ``void *buf''. Those methods are now entirely responsible for converting a register to/from the specified value. There is defenitely something wrong here. The first thing is that in valops.c:value_assign() you call CONVERT_REGISTER_P as follows: + if (CONVERT_REGISTER_P (VALUE_REGNO (toval), VALUE_TYPE (toval))) This is wrong for the lval_reg_frame_relative case. Replacing `VALUE_REGNO (toval)' with `value_reg' seems the obvious solution, and indeed, this makes us execute the following line: + VALUE_TO_REGISTER (frame, fromval); This is strange. Which register should FROMVAL be stored in? That information is contained in TOVAL. Passing TOVAL here is also wrong, since the contents of the value are contained in FROMVAL. A possible solution is passing the register number to VALUE_TO_REGISTER. Another solution is assigning the contents of FROMVAL to (a copy of) TOVAL and pass the latter to VALUE_TO_REGISTER. This seems to be what you had in mind when you wrote the MIPS implementation of VALUE_TO_REGISTER. Besides this issue I have a few other comments on these interfaces. 1. I think it is a good idea to ask the following question again: Why do we have both lval_register and lval_reg_frame_relative? Both seem to deal with values stored in registers. Yes, these can be frame-relative or not. But wouldn't it be better to let VALUE_FRAME_ID() indicate this? A value of null_frame_id would then indicate a global register variable. I may be mistaken, but I think this has consequences for the REGISTER_TO_VALUE interface. Instead of an interface that constructs the complete value, I think we need an interface that just fetches the contents from the appropriate registers; something that is similar to what we have now. 2. What do we guarantee about the `struct value' that is passed to VALUE_TO_REGISTER? That it is created by REGISTER_TO_VALUE? - Adds the possibly contraversal put_frame_register method. It turned out that at least three functions contained the code sequence: find REGNUM's true location, store the value in that location. Nothing against the function, but can we try to keep the naming of the register functions a bit more symmetrical? Anyway, I don't think you should check this in just yet. It definitely needs some more discussion. Mark