This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: WIP: Register doco
I'm not saying the questions below couldn't be worked out by examining
the whole document carefully. But ideally, a document makes sense in
the first read-through.
So, you're saying that this document doesn't make sense on a first
reading? I'm not suprized! :-)
@table @emph
@item cooked
@itemize @bullet
@item
manipulated by core @value{GDBN}
@item
correspond to user level, or abi registers
Don't you mean "ISA" here, not "ABI"? If I disassemble some code and
see an instruction that refers to r12, then I should be able to see
that register's value by saying "print $r12". The ABI in use has
nothing to do with it.
No, ABI. For instance mipsIII and o32. The o32 ABI thinks registers
have 32 bits yet the real register has 64 bits. This gives two views of
the same register. When o32 debug info indicates a value in two
adjacent registers, it is refering to 32 bit and not 64 bit registers.
(Should user visible registers be displayed according to the underlying
ISA or ABI is an item for debate. It has never been specified and I
suspect in part because GDB, prior to gdbarch_register_read/write,
couldn't handle both.)
@end itemize
@item raw
@itemize @bullet
@item
manipulated by target backends
@item
correspond to physical registers
I think you're introducing a new term here, "physical", which doesn't
do anything for you. When I see "physical", I think of actual
flip-flops. But that's clearly not what you're talking about: GDB has
no idea how many ports these registers have, whether they get renamed
for speculative execution, etc.
That was the intent. The objective is to focus the reader on the target
architecture's hardware and identify the registers that correspond to
real hardware. Often in GDB, people haven't focused on the hardware and
its registers and instead stored cooked registers in the raw register
cache. See older SH and bank registers or d10v and its two stack pointers.
However, often, what GDB gets access to is actually the ``spill
registers'' - the hardware registers saved to memory. I guess I should
refine this.
(Mind you, with a jtag target, it really is NAND and NOR gates :-)
In effect, all that phrase does is define "raw" in terms of another
undefined term, "physical".
By "raw", do you really mean the registers as presented by the
underlying protocol GDB uses to examine the inferior (be it remote,
/proc, or ptrace)? I dunno.
I'll likely change it to ``hardware'', I think I've been using that term
more consistently elsewhere.
@item
For a 64 bit architecture that is running in 32 bit mode, the register
cache and raw register space would contain the 64 bit hardware
registers. The raw register space would not include cut down 32 bit
registers.
By "32 bit mode", do you mean that there's an actual bit on the
processor that makes shift, divide, etc. instructions behave as if
there were only 32 bits? Or do you mean an ABI that simply only uses
the lower 32 bits of the registers?
Who knows --- target architecture dependant detail. Some targets have a
true 32 bit mode, some just run 32 bit ABI's on a 64 bit architectures.
The MIPS floating point registers and their various modes shows how
tangled the web can get.
@item
For an architecture that has memory mapped registers, those registers
are not be part of the register cache or raw register space (there is no
corresponding hardware register).
I think it would be nice to use the IA-64's arrangement as an example
here. I assume the raw registers would include the unrotated register
file, and the registers that determine how they're rotated at the
current point. Whereas the cooked registers would be numbered the way
they appear in the machine instructions.
As a description of memory registers or bank registers? Your
description of the IA-64 sounds more like bank selectable registers and
similar --- the FP register stack of the i386 is an example that more
people might be familar with. (Remember we're talking theory here,
neither the ia64 nor the i386 use this mechanism.)
Some architectures can refer to memory addresses using a register like
notation. In fact I know of one architecture where every memory
location can also be refered to using a register notation. Such an
architecture would have zero raw registers.
@itemize @bullet
@item
registers refered to by debug information
@item
user visible registers (specified by name)
@item
mode dependant registers (e.g., a 64 bit architecture in 32 bit mode may
need to manipulate the 32 bits of 64 bit registers)
@item
memory mapped registers
space.
@item
state dependant registers (e.g., bank registers)
@end itemize
Architecture methods then map the @code{NUM_REGS + NUM_PSEUDO_REGS}
cooked registers onto raw registers or memory.
So pseudo registers are different from cooked registers? Or are they
the same? If they're the same, then distinguishing NUM_REGS and
NUM_PSEUDO_REGS sort of implies that NUM_REGS corresponds to the
number of raw registers. But that shouldn't be visible to the outside
at all.
Pseudo registers? Beyond the constant NUM_PSEUDO_REGS, this section
makes no reference to pseudo-registers.
I guess I should add an historical note to the opening section pointing
out that the constant NUM_PSEUDO_REGS originated from an earlier
mechanism called ``pseudo registers''. While, for the moment, the
constant remains, new targets use gdbarch register read/write and not
pseudo registers.
cooked: [0..NUM_REGS)
| \
| \
| \
| \
raw: RAW REGISTERS MEMORY
In other words, given that we're allowing cooked registers to be
computed arbitrarily from raw registers and memory contents, why not
dispense with pseudo registers altogether?
The need for pseudo registers was dispensed with a year ago. Someone
just needs to clean up the old targets and cleanup some edge cases ....
As for NUM_REGS, that defines the number of registers in the raw
register cache (note below).
I'll add a comment mentioning the rationale behind direct mapping the
first [0..NUM_REGS) registers. It was firstly a case of K.I.S.S. and
secondly due to suspected limitations in the current GDB code - the
constant NUM_REGS unfortunatly still determines far more than the number
of raw registers. You may want to read the e-mail exchange between
myself and RichardE as it contains all the gorry details.
I think I'll also add a simplified version of the diagraram to the
opening section.
thanks for all the comments,
enjoy,
Andrew