From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15489 invoked by alias); 22 May 2007 15:58:53 -0000 Received: (qmail 15463 invoked by uid 22791); 22 May 2007 15:58:50 -0000 X-Spam-Check-By: sourceware.org Received: from mms2.broadcom.com (HELO mms2.broadcom.com) (216.31.210.18) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 22 May 2007 15:58:46 +0000 Received: from [10.10.64.154] by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.1)); Tue, 22 May 2007 08:58:30 -0700 X-Server-Uuid: A6C4E0AE-A7F0-449F-BAE7-7FA0D737AC76 Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id D18E42AF; Tue, 22 May 2007 08:58:30 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id BE53B2AE for ; Tue, 22 May 2007 08:58:30 -0700 (PDT) Received: from mail-irva-12.broadcom.com (mail-irva-12.broadcom.com [10.10.64.146]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id FHV63199; Tue, 22 May 2007 08:58:30 -0700 (PDT) Received: from NT-IRVA-0752.brcm.ad.broadcom.com ( nt-irva-0752.brcm.ad.broadcom.com [10.8.194.67]) by mail-irva-12.broadcom.com (Postfix) with ESMTP id 7495169CA3 for ; Tue, 22 May 2007 08:58:30 -0700 (PDT) Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: Info reg sp Date: Tue, 22 May 2007 15:58:00 -0000 Message-ID: In-Reply-To: <20070522153414.GA23001@caradoc.them.org> References: <20070522153414.GA23001@caradoc.them.org> From: "Robert Norton" To: gdb@sourceware.org X-WSS-ID: 6A4DCCAC37W2507113-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2007-05/txt/msg00108.txt.bz2 Thanks for your response. > -----Original Message----- > From: Daniel Jacobowitz [mailto:drow@false.org]=20 > Sent: 22 May 2007 16:34 > > Hmm, good question. I could make an argument either way.=20=20 > Every port has this same problem, but then again only the=20 > default print_registers_info and those with their own=20 > print_registers_info would have to be fixed. The default print_registers seems to be immune to this by virtue of the (slightly weird) for loop which compares every number less than NUM_REGS+NUM_PSEUDO_REGS to regnum when printing a value! Design or happy coincidence -- who can tell?=20 =20 > Still, it's nasty that value_of_register can handle user=20 > registers but nothing else can. Maybe frame.c should also? >=20 > I've been starting to use user registers more heavily lately,=20 > since pseudo registers have strange problems - they only come=20 > from a regcache, not from a frame. I'm not clear on the meaning of PSEUDO_REGS vs. user regs but it seems that if something like this can happen it should at least be documented. There isn't currently any documentation on the meaning of print_registers_info in gdbarch.sh, where I would expect to find it, but the following found in infcmd.c doesn't mention this possibility: /* Print out the machine register regnum. If regnum is -1, print all registers (print_all =3D=3D 1) or all non-float and non-vector registers (print_all =3D=3D 0). For most machines, having all_registers_info() print the register(s) one per line is good enough. If a different format is required, (eg, for MIPS or Pyramid 90x, which both have lots of regs), or there is an existing convention for showing all the registers, define the architecture method PRINT_REGISTERS_INFO to provide that format. */ Cheers, =20 Robert