From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9229 invoked by alias); 12 Apr 2006 19:25:09 -0000 Received: (qmail 9216 invoked by uid 22791); 12 Apr 2006 19:25:08 -0000 X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 12 Apr 2006 19:25:06 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k3CJP4TV002346 for ; Wed, 12 Apr 2006 15:25:04 -0400 Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.11.6) with ESMTP id k3CJP3eH023430 for ; Wed, 12 Apr 2006 15:25:03 -0400 Received: from [172.16.24.50] (bluegiant.sfbay.redhat.com [172.16.24.50]) by potter.sfbay.redhat.com (8.12.8/8.12.8) with ESMTP id k3CJP2Tq023243 for ; Wed, 12 Apr 2006 15:25:02 -0400 Message-ID: <443D540D.2050902@redhat.com> Date: Wed, 12 Apr 2006 19:25:00 -0000 From: Michael Snyder User-Agent: Mozilla Thunderbird 1.0.7-1.4.1 (X11/20050929) MIME-Version: 1.0 To: GDB Patches Subject: Re: [PATCH]: Don't use deprecated regcache functions References: <20060411.013909.129717839.davem@davemloft.net> <20060411130057.GA21369@nevyn.them.org> <20060411.141334.116677120.davem@davemloft.net> In-Reply-To: <20060411.141334.116677120.davem@davemloft.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-04/txt/msg00156.txt.bz2 David S. Miller wrote: > From: Daniel Jacobowitz > Date: Tue, 11 Apr 2006 09:00:57 -0400 > > >>On Tue, Apr 11, 2006 at 01:39:09AM -0700, David S. Miller wrote: >> >>>Otherwise, ok to apply? >> >>>- deprecated_read_register_gen (regno, raw); >>>+ regcache_raw_collect (current_regcache, regno, raw); >>> thread_db_fetch_registers (-1); >>> regcache_raw_supply (current_regcache, regno, raw); >> >>I might be mistaken, but what the heck does the call to >>thread_db_fetch_registers accomplish? I think nothing. Daniel, David's got the right of it. > The solaris thread support does the same thing. And that code > uses the more correct regcache_raw_collect() which is partly how > I noticed this. > > What's happening here is that if we're only writing one register > we make sure to read in all the other registers first, then we > write the changing register back into the regcache. > > This is interrelated with another piece of gdb code history I > was researching last night when I ran across this. Several > platforms used to define CHILD_PREPARE_TO_STORE in order to > deal with interfaces, such as some ptrace() variants, that can > only set the whole set of registers at once. > > There are some really nasty cases on Sparc for example, say you > want to write just the stack pointer. We obtain the local and > in registers from the on-stack save area, so if we were not careful > just changing the stack or the frame pointer would cause all of > those other registers to change even though that is not what we > intended. So to do it right, you have to read all the registers > into the regcache, then modify the stack or frame pointer. > > This CHILD_PREPARE_TO_STORE macro would get invoked by the > target_prepare_to_store(). If you look at the regcache code it always > does a sequence like this: > > target_prepare_to_store (); > memcpy (register_buffer (regcache, regnum), buf, > regcache->descr->sizeof_register[regnum]); > regcache->register_valid_p[regnum] = 1; > target_store_registers (regnum); > > So, if necessary, target_prepare_to_store() would make sure the > regcache was fully read in if not already, then it would be safe to > write into the register cache. > > But it seems that Mark Kettenis has been trying to transition > away from this deprecated scheme, and instead handle this issue > inside of the store register methods of the individual targets > and native support modules. > > In fact, the only platform defining CHILD_PREPARE_TO_STORE is > GNU Hurd on x86, and probably that will eventually be eliminated > as well, and along with it target_prepare_to_store() and all > assosciated hooks. > > In any event, the code we are discussing here in the Linux thread_db > code really is needed and it's related to the issues I've discussed > above. > > So I think it's ok to apply this :-) >