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] |
>> Hmm, what exactly do you mean by mimicked? Can the entire register >> contents be constructed from information found in the other raw/hardware >> registers? If that is the case then making it a pseudo-register and >> using register_{read,write} should do the trick. >> >> (notice - convert-to-virtual free zone). (and how I'm quietly eliminating it :-) > In the case where the real register does not exist (arm2, arm3), or when > the register doesn't exist in the current operating mode (arm6, arm7 -- > though not arm7tdmi, arm8 and sa1 when running in apcs-26 mode), then the > CPSR is part of the PC and we mimic its existence within GDB; so yes, in > that case it is a virtual register. > But when we are running in pure apcs-32 mode, then CPSR is a separate > register (with additional bits defined). In APCS-32 mode, is there any overlap of information between it and the PC? > The more I think about it, the more I think that the raw<->virtual > translation is in the wrong part of GDB. Shouldn't this be part of the > Target interface? Then conversion to/from virtual format would happen as > data is passed to/from the inferior, and the rest of GDB would only use > the virtual format. Yes, I agree that raw<->virtual is wrong; but no, it shouldn't be pushed down below the target. > As I understand it, this would clean up the MIPS issue entirely -- when > talking to a target that supplies additional bits for a register, the > target layer would strip these off/add them back, and the rest of gdb > wouldn't have to worry about it. Have a look at the SH5 patch. I think this gets it right. The first cut at all this had the target using supply_register() to fill in missing values in from below the cache - turns out this makes coherency hard. The current revision uses register_{read,write} above the cache to do this, thus eliminating redundant information in the cache. For the SH5, the raw register cache contains SHmedia (32/64 bit?) registers (as that is what the raw hardware has). Pseudo-registers, and register_{read,write} are then used to map SHcompact (16/32?) registers onto the corresponding raw registers. For instance, the SHcompact PC (I'm going from memory) is constructed from two SHmedia registers. This is implemented by having register_{read,write} scatter/gather the relvant value. Other SHcompact registers are sub registers of SHmedia and they are implemented using similar techniques. When it comes to a frame, a custom get_saved_register() handles the related problem of SHmedia X SHcompact frame vs request for SHmedia X SHcompact register from the next outer frame (I suspect with a few lingering edge cases :-). Andrew
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |