Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: "Robert Norton" <rnorton@broadcom.com>
To: gdb@sourceware.org
Subject: RE: Info reg sp
Date: Tue, 22 May 2007 15:58:00 -0000	[thread overview]
Message-ID: <B0D822BFECD50F4991F2516EA50F273C018F9AF2@NT-IRVA-0752.brcm.ad.broadcom.com> (raw)
In-Reply-To: <20070522153414.GA23001@caradoc.them.org>

Thanks for your response.

> -----Original Message-----
> From: Daniel Jacobowitz [mailto:drow@false.org] 
> Sent: 22 May 2007 16:34
>
> Hmm, good question.  I could make an argument either way.  
> Every port has this same problem, but then again only the 
> default print_registers_info and those with their own 
> 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? 
 
> Still, it's nasty that value_of_register can handle user 
> registers but nothing else can.  Maybe frame.c should also?
> 
> I've been starting to use user registers more heavily lately, 
> since pseudo registers have strange problems - they only come 
> 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 == 1) or all non-float and non-vector
   registers (print_all == 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,
 
Robert


  reply	other threads:[~2007-05-22 15:58 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-05-22 15:24 Robert Norton
2007-05-22 15:34 ` Daniel Jacobowitz
2007-05-22 15:58   ` Robert Norton [this message]
2007-05-22 16:32     ` Daniel Jacobowitz
2007-05-22 16:47       ` Robert Norton

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=B0D822BFECD50F4991F2516EA50F273C018F9AF2@NT-IRVA-0752.brcm.ad.broadcom.com \
    --to=rnorton@broadcom.com \
    --cc=gdb@sourceware.org \
    /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