Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Andrew Cagney <ac131313@ges.redhat.com>
To: Daniel Jacobowitz <drow@mvista.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [patch/rfc] Don't include vector registers in ``info registers''
Date: Thu, 08 Aug 2002 19:35:00 -0000	[thread overview]
Message-ID: <3D532A5E.7020706@ges.redhat.com> (raw)
In-Reply-To: <20020809013343.GA5331@nevyn.them.org>

> On Thu, Aug 08, 2002 at 07:51:57PM -0400, Andrew Cagney wrote:
> 
>> Hello,
>> 
>> The attached patch modifies the generic ``info registsters'' command so 
>> that it precludes vector registers (in addition to floating-point 
>> registers).  The online doco indicates:
>> 
>> (gdb) help info registers
>> List of integer registers and their contents, for selected stack frame.
>> Register name as argument means describe only that register.
>> (gdb) help info all-registers
>> List of all registers and their contents, for selected stack frame.
>> Register name as argument means describe only that register.
>> 
>> I think the change makes the behavour a better match for both the 
>> documentation and what I think is the intent of the command.  Print a 
>> minimal set of registers.
>> 
>> It will eventually affect the i386 -- I've a patch to change the type of 
>> xmm [and mmx] registers to true vectors.  When that is in, ``info 
>> registers'' will stop displaying the xmm registers.
>> 
>> Thoughts?
> 
> 
> My only comment is that I would also like ``info registers'' not to
> print kernel-mode or processor status registers, since that seems (to
> me) to be appropriate; it should print registers for stack/pc and
> computation primarily, not things like the MSR.

Yes.

There has been talk of adding a register attribute function.  I suspect, 
though, that the function is of more use to GUI's then the CLI.

> Might be harder to do generically though.

Yes.

I suspect the reality is that every architecture will eventually ends up 
with a custom info-registers function.   Simply because they want the 
output to be something useful.  Might even end up doing this for the i386.

I think we need to be careful to not fall into the trap of over 
engineering the default function.  Instead, encourage each target to do 
it custom but do provide some useful register print routines.

--

Thinking out loud.  Perhaphs the default ``info float[-registers]'' 
should scan for and print any floating-point registers and only print 
``no float'' if none are found.

enjoy,
Andrew



  parent reply	other threads:[~2002-08-09  2:35 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-08-08 16:52 Andrew Cagney
2002-08-08 17:07 ` Andrew Cagney
2002-08-08 19:07   ` Elena Zannoni
2002-08-08 19:24     ` Andrew Cagney
2002-08-13 14:45     ` Andrew Cagney
2002-08-09 11:39   ` Andrew Cagney
2002-08-15 17:12   ` Andrew Cagney
2002-08-08 18:33 ` Daniel Jacobowitz
2002-08-08 18:45   ` Michael Snyder
2002-08-08 19:35   ` Andrew Cagney [this message]
2002-08-08 18:50 ` Michael Snyder

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3D532A5E.7020706@ges.redhat.com \
    --to=ac131313@ges.redhat.com \
    --cc=drow@mvista.com \
    --cc=gdb-patches@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox