From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30073 invoked by alias); 4 Jun 2003 23:05:12 -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 30040 invoked from network); 4 Jun 2003 23:05:11 -0000 Received: from unknown (HELO localhost.redhat.com) (207.219.125.131) by sources.redhat.com with SMTP; 4 Jun 2003 23:05:11 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id B46A02B2F; Wed, 4 Jun 2003 19:05:05 -0400 (EDT) Message-ID: <3EDE7B21.6050603@redhat.com> Date: Wed, 04 Jun 2003 23:05:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030223 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Kettenis Cc: gdb-patches@sources.redhat.com Subject: Re: [wip/rfc] Merge REGISTER_TO_VALUE and REGISTER_TO_TYPE References: <3EDE4A9E.70403@redhat.com> <8665nl34ao.fsf@elgar.kettenis.dyndns.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-06/txt/msg00188.txt.bz2 > Andrew Cagney writes: > > [snip] > > >> With this in mind, I'm thinking that REGISTER_TO_TYPE and >> REGISTER_TO_VALUE should be merged. To that end, I can see several ways >> of doing it: >> >> - Don't merge - add REGISTER_TO_TYPE to the architecture vector >> >> - Retain the current logic - just apply REGISTER_TO_VALUE to values >> stored across multiple registers >> >> - Add a frame parameter to REGISTER_TO_VALUE and make it responsible for >> both extracting the bytes from the register[s] and then storing them in >> the ``struct value''. >> >> The last option is interesting, it would let the target draw the value >> from any register based on REGNUM. The i386 with its long-long problem >> might be interested in this (you'll notice in the patch I made an >> attempt at doing this only I didn't see it affect the test results). >> >> Thoughts? > > > The last option is certainly attractive. The fact that this doesn't > show any improvements in the testsuite, is because there is no test > for `long long' in store.exp. What about reading long long values? Nothing there either? The changes, as they stand, don't touch the path used when storing (note the #if 0 in the patch ....). > There are tests for small structs there > that will still fail since your implementation of > i386_register_to_value isn't complete; it should also handle 8-byte > strcutures stored in registers. Not just integers. > > Anyway, you can leave the i386-specific details to me if you prefer. M'kay. Andrew