This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: [RFC]: Pseudo-registers for GDB


> Date: Tue, 11 Jul 2000 18:00:15 -0700
> From: Michael Snyder <msnyder@cygnus.com>
> 
> > Not really.  In the case in point, only 64 out of 80 bits are used in
> > the MMX mode, while the FP mode uses all 80 bits.  It is not clear
> > what to do with the rest of the bits when you are in the MMX mode.
> 
> Well, but I mean, the raw form of the register that GDB sees
> will be 10 bytes, right?  It's the virtual form that's 8 bytes?
> Bottom like is, the MMX register and the FP register share
> the same storage?

Yes, on all three counts.  The problem is how do you tell GDB that
these registers share the same storage.  Various high-level layers of
GDB are currently not ready for this situation.  You need either to
invoke a target-specific function to update a register, or somehow
communicate the fact that several registers share the same storage to
the GDB application level, e.g. by letting the target or the
architecture specify attributes of each register.

In other words, it sounds like a change in the way GDB represents
registers is required.  We need a struct with attributes, pointers to
aliased registers, overlap/offset info, etc.

> No, as I envision things, GDB would only write the "real"
> registers back to the target.  The "pseudo-registers" would
> be like internal variables -- computed, not fetched or stored.
> There would be only one (ten byte) storage location in GDB
> shared by the FP register and the MMX register.  The difference
> between the two would be only the name and possibly how the 
> data was interpreted.

This should work, but I think there must be a way of telling the
target-specific part which representation was used to store the data
in the register, because (at least in the case of MMX) the
target-specific code might need slight changes in how it passes
registers back to the inferior, depending on this info.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]