This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: RFA: make sim interface use gdbarch methods for collect/supply
On Thu, Jul 15, 2004 at 01:30:22PM -0500, Jim Blandy wrote:
>
> Daniel Jacobowitz <drow@false.org> writes:
> > On Tue, Jul 06, 2004 at 12:09:15PM -0500, Jim Blandy wrote:
> > > Daniel Jacobowitz <drow@false.org> writes:
> > > > A more practical approach would probably be to maintain a mapping of
> > > > the remote protocol register numbers to GDB's internal register numbers
> > > > in addition to register sets. I don't see any problem with that.
> > >
> > > What if the remote protocol wants to talk about a 64-bit register, but
> > > GDB's raw regcache sees that as two 32-bit registers? A simple
> > > number-to-number mapping doesn't do the trick.
> >
> > Don't do that then. Pass those as a regset, not numbered in the T
> > packet.
>
> You're saying that, since we include register values in the T packet
> just for expedience, we can always decline to do that when it's hard,
> right? But whether it's hard or not depends on GDB's raw regcache
> layout, which isn't supposed to be a matter of public interface. When
> someone needs to rearrange the raw regcache, the set of registers
> which can be profitably provided in a T packet changes. That's not
> the way it should be.
>
> > Or have the register renumbering function map that number to the
> > combined pseudo register!
>
> But what would GDB's code handling that packet do with that pseudo-
> register number? It can't pass it to a regset or per-register
> "supply" function.
Then perhaps that should be changed. In practice, many
pseudo-registers are suppliable. It might even be possible to
rearrange the interfaces such that *_pseudo_register_write can be used,
via regcache_cooked_write, i.e. supply cooked registers.
This would require rethinking of the raw/cooked boundary. Currently
the boundary is that raw registers are those we can query the target
for. If you have a remote target that can not supply the same
registers we keep in the raw regcache, we have a design problem.
--
Daniel Jacobowitz