Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Andrew Cagney <ac131313@ges.redhat.com>
To: Jim Blandy <jimb@redhat.com>
Cc: gdb@sources.redhat.com
Subject: Re: WIP: Register doco
Date: Sun, 21 Jul 2002 09:41:00 -0000	[thread overview]
Message-ID: <3D3AE41B.10201@ges.redhat.com> (raw)
In-Reply-To: <npvg7aaveq.fsf@zwingli.cygnus.com>


> No, I think we need to draw the GDB developer's eye *to* those glossy
> user-level ISA specs.  :) Figure 8-1 --- the first diagram in the
> chapter titled "Programming with the X87 FPU" --- has R0 -- R7 right
> there.  The second diagram, figure 8-2, shows how the TOP field
> affects the relationship between ST(i) and Ri.  The fact that there is
> a fixed set of registers accessed as a rotating stack is very much
> part of the ISA documentation.

I was talking generally.

However looking at specific manual set(1) 
(http://developer.intel.com/design/pentium4/manuals), vol1 is the user 
stuff; vol3 is the system stuff.  The GDB developer needs to look beyond 
vol1 and and into vol3.  Vol1 8.1.10 Saving the x87 FPU's State with the 
FXSAVE Instruction, for instance, just points the reader at volume 3. 
In addition, the GDB developer ends up studying kernel interfaces and 
too often (ulgh!) kernel sources.

Taking a step back.  Cooked registers are at the level of the user 
and/or ABI.  Raw registers are at the level of the underlying 
system/hardware.  The GDB developer needs to be familar with both.  More 
importantly, and as I mentioned last time, we need to be very careful to 
ensure that the GDB developer looks beyond that user model and on down 
to the lower level details of the architecture.

> As a sanity check, assuming that SPARC register windows are analogous:
> the SPARC ISA spec talks about register windows immediately, as well.
> Figure 2 in the chapter on Registers shows "Three Overlapping Windows
> and the Eight Global Registers".  (For some reason, that makes me
> think of Goldilocks and the Three Bears.)

Just FYI, an example involving the SPARC is on my things todo list for 
frames.  It turns out that the OS for a register-window architecture 
typically flushes all but the inner most window to memory before 
transfering control to GDB.  Consequently the only raw registers that 
GDB sees are those that are innermost.  It is the frame, and not the 
register cache code, that needs to handle this one.

enjoy,
Andrew

(1) The ia32 manual set is badly organized.  Try figuring out the full 
set of registers (user and system) on, say, a p4.


  reply	other threads:[~2002-07-21 16:41 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-07-19 17:31 Andrew Cagney
2002-07-19 20:11 ` Jim Blandy
2002-07-20 11:39   ` Andrew Cagney
2002-07-20 11:36     ` Jim Blandy
2002-07-20 13:41       ` Andrew Cagney
2002-07-20 15:26         ` Jim Blandy
2002-07-21  9:41           ` Andrew Cagney [this message]
2002-07-21 10:04             ` Daniel Jacobowitz
2002-07-22  9:38               ` Andrew Cagney
2002-07-22 10:30                 ` Daniel Jacobowitz
2002-07-23 16:25             ` Jim Blandy
2002-07-23 17:34               ` Andrew Cagney
2002-07-23 20:45                 ` Jim Blandy
2002-07-24  8:35                   ` Andrew Cagney
2002-07-24 22:08                     ` Jim Blandy
2002-07-25  8:13                       ` Andrew Cagney
2002-07-23 21:17                 ` Jim Blandy
2002-07-24  9:09                   ` Andrew Cagney
2002-07-24 22:03                     ` Jim Blandy
2002-07-25  8:11                       ` Andrew Cagney
2002-07-22 14:39         ` Mark Kettenis
2002-07-22 14:41         ` Mark Kettenis

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=3D3AE41B.10201@ges.redhat.com \
    --to=ac131313@ges.redhat.com \
    --cc=gdb@sources.redhat.com \
    --cc=jimb@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