From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30406 invoked by alias); 20 Apr 2002 02:10:28 -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 30392 invoked from network); 20 Apr 2002 02:10:23 -0000 Received: from unknown (HELO pizda.ninka.net) (216.101.162.242) by sources.redhat.com with SMTP; 20 Apr 2002 02:10:23 -0000 Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id TAA09031; Fri, 19 Apr 2002 19:01:43 -0700 Date: Fri, 19 Apr 2002 19:10:00 -0000 Message-Id: <20020419.190143.102963762.davem@redhat.com> To: msnyder@redhat.com Cc: gdb-patches@sources.redhat.com Subject: Re: [RFA] Linux/Sparc patch 3 From: "David S. Miller" In-Reply-To: <3CC0CA32.DB078FAC@redhat.com> References: <20020419.155406.122216612.davem@redhat.com> <3CC0CA32.DB078FAC@redhat.com> Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2002-04/txt/msg00661.txt.bz2 From: Michael Snyder Date: Fri, 19 Apr 2002 18:53:54 -0700 "David S. Miller" wrote: > The child_xfer_memory implementation in infptrace.c is > SLOWWWWWWW... Especially when we have fully functional > PTRACE_{READ,WRITE}DATA under Linux/Sparc. Interesting ... could we benefit from making this change on other (perhaps all) linux architectures? If so, might it be possible to make the change in a single place? Only Linux/Sparc supports PTRACE_{READ,WRITE}DATA, nyah nyah :-) > Another bug fix is that we need to make sure all registers > are read before store takes place, thus we define > CHILD_PREPARE_TO_STORE. All the BSD'ish Sparc ports set > this as well, for the same reason. Seems perfectly reasonable. Is this also something that should be done for all linuxen? No, it is a Sparc specific issue. Can I ask you to read my changes when reviewing them? I describe the situation precisely in the comment above this define, and I make it clear that this is a Sparc specific issue. If my comment doesn't make this clear, show me how to make it so. :-) > We also define PTRACE_*_TYPE in preparation for 64-bit support. This seems like it could benefit from using multi-arch... Please wait until the facility to do this is really there. See my other emails about OS specific gdbarch init calls These values only matter for native ptrace calls anyways, I don't see why you'd bother multi-arching it. Franks a lot, David S. Miller davem@redhat.com