From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12607 invoked by alias); 9 Feb 2006 14:16:27 -0000 Received: (qmail 12594 invoked by uid 22791); 9 Feb 2006 14:16:27 -0000 X-Spam-Check-By: sourceware.org Received: from linuxupdserver.utsp.utwente.nl (HELO linuxupdserver.utsp.utwente.nl) (130.89.1.83) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 09 Feb 2006 14:16:25 +0000 Received: from weblx058.utsp.utwente.nl (weblx058.utsp.utwente.nl [130.89.1.228]) by linuxupdserver.utsp.utwente.nl (8.11.7/HKD) with SMTP id k19EFrI17456; Thu, 9 Feb 2006 15:15:53 +0100 From: "M.M. Kettenis" Subject: Re: ia64 register cache (not!) MIME-Version: 1.0 Date: Thu, 09 Feb 2006 14:16:00 -0000 Message-Id: <7323515135308169@webhare> X-WebHare-Origin: WebHare Organizer To: David Lecomber , gdb@sources.redhat.com In-reply-to: <20060209123032.GA10585@streamline-computing.com> Content-Description: Message body Content-Type: text/plain; charset="US-ASCII"; format=flowed Content-Transfer-Encoding: Quoted-Printable X-UTwente-MailScanner-Information: Scanned by MailScanner. Contact helpdesk@ITBE.utwente.nl for more information. X-UTwente-MailScanner: Found to be clean X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-02/txt/msg00064.txt.bz2 David Lecomber wrote: > Dear all, > > The ia64 (on suse9.3) of gdb seems to not use the PTRACE_GETREGS, but > goes fetching each register in turn. This seems a bit crazy, and the > source of some very slow behaviour (given the number of ia64 registers!). > > There seems to be some source that was intended to handle the GETREGS > but is probably not being called (ia64-linux-nat.c). > > When I debug, gdb is definitely calling the fetch_inferior_registers > defined inside infptrace.c (btw, this is GDB from June'05, but it seems > that the excessive ptrace behaviour is the same in most recent CVS too).. > > Anyone have an idea why it's this way? I've watched how gdb handles the > i386 version -- going off into fetch_inferior_registers in i386-linux-nat= .c. Are you sure the ia64 kernel supports the PTRACE_GETREGS/PTRACE_SETREGS requests? If those are implemented someone really should add support for them. Note that even if the current kernels do, there may be older kernels that don't have these. A possible solution would be to use PTRACE_GETREGS if available and fall back on PTRACE_PEEK_USER if it isn't (that's what we do on Linux/i386). But if kernels without PTRACE_GETREGS are no longer in widespread use, it's probably not worth bothering. Mark