This is the mail archive of the gdb@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] |
On Thu, Sep 04, 2003 at 10:00:39AM -0400, Andrew Cagney wrote:
>Hmm, yes and no. That definition of regset is only useful for core >files; I would like something more generally useful, for remote and >native use. I also don't really like passing the core gdbarch around, >for the same reason. How about this instead? > >struct regset >{ > void (*supply_regset)(struct regcache *, const void *, size_t, int); > void (*read_regset)(struct regcache *, void *, size_t, int); >}; > >const struct regset * >core_section_to_regset (struct gdbarch *core_gdbarch, > const char *sec_name, size_t sec_size); > >which would then allow: > >const struct regset * >remote_name_to_regset (const char *name);
As far as I know, the required lookups are:
REGNUM -> REGSET
foreach REGSET
and not SETNAME -> REGSET. This is so that a request for a single register, or all registers, can be directed to the correct regset. I also think having remote and corefile adopt an identical naming schema should make life easier.
I'd really rather not enforce that - remote can provide regsets that BFD doesn't know about, and the ".reg" names would look silly being defined as part of the remote protocol. My instinct says that the flexibility is worthwhile so that the two implementation details don't become coupled.
I believe REGSET->SETNAME is necessary for the remote protocol approach I described. Don't necessarily want to fetch all register sets, so we need to figure out the name of the one we do want. You could implement the core side with REGSET->SETNAME and foreach REGSET, but I think it's more straightforward with SETNAME->REGSET.
Also, core_section_to_regset is more than just SETNAME->REGSET. It considers the regset's size and core file's architecture, for reasons Mark described.
As for the architecture, supply_regset needs this. It might, for instance, be an x86-64 method supplying registers to an i386 register cache.
It needs the regcache's architecture, but I don't believe it needs any other. The method will be defined for a particular regcache layout, which incorporates all of the information it needs about the other involved architecture. We could get the regcache's architecture from the regcache, or pass it explicitly.
I should note that I do know of a second way of handling cross architectures (x86-64 on i386 et.al.). Add a table of cross architecture unwinders and then allow different frames to have different architectures vis:
x86-64 frame <x86-64 X i386> i386 frame i386 frame <ia64 X i386> ia64 frame
but that's getting way ahead of many other changes.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |