From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20735 invoked by alias); 12 Mar 2003 15:35:16 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 20724 invoked from network); 12 Mar 2003 15:35:15 -0000 Received: from unknown (HELO localhost.redhat.com) (172.16.49.200) by 172.16.49.205 with SMTP; 12 Mar 2003 15:35:15 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 4EB782B11; Wed, 12 Mar 2003 10:35:15 -0500 (EST) Message-ID: <3E6F53B3.6010803@redhat.com> Date: Wed, 12 Mar 2003 15:35: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: Michael Elizabeth Chastain , drow@mvista.com Cc: stcarrez@nerim.fr, brobecker@gnat.com, gdb@sources.redhat.com, kettenis@chello.nl Subject: Re: 8-byte register values on a 32-bit machine References: <200303021659.h22Gxc908446@duracef.shout.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-03/txt/msg00179.txt.bz2 > Okay, I got some sleep and drank some tea and stuff. I'm a bit more > calm now. :) > > I filed a proper PR, so that Daniel J (or anybody) can flow it into > their TODO list. Daniel said he has several things to do in this code > so I want to get in line properly. > > I did mark it severity=critical because gdb prints incorrect values, and > priority=high because Stephane C says that it happens a lot on the HC11. > > gdb 5.3 has a different bug in the same area, so this is only sort-of a > regression. The specific program store.exp in the test suite regressed > between 2003-02-15 and 2003-02-23, but my test program r8.c in the PR is > busted with both gdb 5.3 and gdb 2003-03-01-cvs. Shouldn't the new code have been made conditional until it at least equalled the functionality of the old mechanism? By failing to do this to do this, the next release of GDB has gained a dependency on the timetable of an internal change. That is bad. Andrew