From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25638 invoked by alias); 28 Mar 2002 20:21:34 -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 25630 invoked from network); 28 Mar 2002 20:21:32 -0000 Received: from unknown (HELO cygnus.com) (205.180.230.5) by sources.redhat.com with SMTP; 28 Mar 2002 20:21:32 -0000 Received: from redhat.com (notinuse.cygnus.com [205.180.231.12]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id MAA24774; Thu, 28 Mar 2002 12:21:30 -0800 (PST) Message-ID: <3CA378BC.A127FBDB@redhat.com> Date: Thu, 28 Mar 2002 12:21:00 -0000 From: Michael Snyder Organization: Red Hat, Inc. X-Accept-Language: en MIME-Version: 1.0 To: Andrew Cagney CC: Kevin Buettner , gdb-patches@sources.redhat.com Subject: Re: [patch/rfc] Delete write_fp() and friends References: <3CA28E57.9080108@cygnus.com> <3CA360CB.D9D579AA@redhat.com> <1020328185523.ZM27447@localhost.localdomain> <3CA3768C.3020906@cygnus.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2002-03/txt/msg00585.txt.bz2 Andrew Cagney wrote: > > > On Mar 28, 10:28am, Michael Snyder wrote: > > > > > >> > Well, almost, I left dwarf2cfi.c's write_fp() as is - someone might be > >> > interested in the code. > >> > > >> > Assuming no issues are raised, and my builds come back clean, I'll > >> > commit it next week. > > > >> > >> So what should calls to write_fp be replaced with? > > > > > > It looks to me like there was only one call to write_fp() and that > > occurred in sparc-tdep.c. Andrew replaced that call with a call to > > write_register(). > > I need to examine that a bit more carefully though. > > > But, ahem, it would've been nice for Andrew to tell us this in the > > prefatory text preceding the patch. > > True, it was intentional - to see who was awake. I figured that a patch > to delete write_fp() was going to be examined very very carefully :-) If no one but Sparc is using it, I'm not very worried (as long as you take care of sparc).