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]
Other format: [Raw text]

Re: RFA: make sim interface use gdbarch methods for collect/supply


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.


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