From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7402 invoked by alias); 11 Apr 2006 21:13:41 -0000 Received: (qmail 7391 invoked by uid 22791); 11 Apr 2006 21:13:40 -0000 X-Spam-Check-By: sourceware.org Received: from dsl027-180-168.sfo1.dsl.speakeasy.net (HELO sunset.davemloft.net) (216.27.180.168) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 11 Apr 2006 21:13:38 +0000 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.60) (envelope-from ) id 1FTQB5-0006G5-4Y; Tue, 11 Apr 2006 14:13:35 -0700 Date: Tue, 11 Apr 2006 21:13:00 -0000 Message-Id: <20060411.141334.116677120.davem@davemloft.net> To: drow@false.org Cc: gdb-patches@sources.redhat.com Subject: Re: [PATCH]: Don't use deprecated regcache functions From: "David S. Miller" In-Reply-To: <20060411130057.GA21369@nevyn.them.org> References: <20060411.013909.129717839.davem@davemloft.net> <20060411130057.GA21369@nevyn.them.org> X-Mailer: Mew version 4.2.53 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii 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/msg00138.txt.bz2 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. 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 :-)