From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19139 invoked by alias); 11 Oct 2002 16:26:04 -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 19129 invoked from network); 11 Oct 2002 16:26:03 -0000 Received: from unknown (HELO mail-out1.apple.com) (17.254.0.52) by sources.redhat.com with SMTP; 11 Oct 2002 16:26:03 -0000 Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out1.apple.com (8.11.3/8.11.3) with ESMTP id g9BGQ2i27075 for ; Fri, 11 Oct 2002 09:26:03 -0700 (PDT) Received: from scv2.apple.com (scv2.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Fri, 11 Oct 2002 09:26:02 -0700 Received: from molly.local. (vpn-scv-x2-217.apple.com [17.219.193.217]) by scv2.apple.com (8.11.3/8.11.3) with ESMTP id g9BGQ1V17666; Fri, 11 Oct 2002 09:26:01 -0700 (PDT) Date: Fri, 11 Oct 2002 09:26:00 -0000 Subject: Re: [PATCH] Print vector registers in natural format, not hex Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v543) Cc: gdb-patches@sources.redhat.com To: Eli Zaretskii From: Klee Dienes In-Reply-To: <2593-Sun06Oct2002212803+0200-eliz@is.elta.co.il> Message-Id: <22199F8A-DD36-11D6-B6D6-00039396EEB8@apple.com> Content-Transfer-Encoding: 7bit X-SW-Source: 2002-10/txt/msg00237.txt.bz2 Eli Zaretskii writes: > Thanks, this is approved. > > Do we have facilities for printing vector registers? If so, we should > probably add a cross-reference to their description here. The > intersted reader will most probably wonder what can she do to print > vector registers when she reads these passages. The closest facility is the 'info vector' command, which by default prints the contents of all vector registers, but is documented simply as "Print the status of the vector unit.", which I take to mean that it can be overridden to have arch-specific output, much like 'info float'. An 'info vector-registers' and 'info fp-registers' command might not be such a bad idea, but none exists at the moment that I know of. We'll also probably need to look at the following chunk of documentation if/when this patch is accepted: > @value{GDBN} always considers the contents of an ordinary register as > an > integer when the register is examined in this way. Some machines have > special registers which can hold nothing but floating point; these > registers are considered to have floating point values. There is no > way > to refer to the contents of an ordinary register as floating point > value > (although you can @emph{print} it as a floating point value with > @samp{print/f $@var{regname}}). Maybe something along the lines of: @value{GDBN} always considers the contents of an ordinary register as an integer when the register is examined in this way. Some machines have special registers that are predefined to have specific types (typically floating point or vector registers); these registers are printed according to their system-defined type. There is no way to refer to the contents of an ordinary register as a floating point value or vector type (although you can @emph{print} it as a floating point value with @samp{print/f $@var{regname}}).