From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cagney To: Nick Duffek Cc: gdb@sources.redhat.com Subject: Re: A better register interface Date: Mon, 26 Feb 2001 16:05:00 -0000 Message-id: <3A9AEED7.77FCB6BE@cygnus.com> References: <3A8B5C60.92EEABA3@cygnus.com> <200102262210.f1QMAC000611@rtl.cygnus.com> X-SW-Source: 2001-02/msg00394.html > If I understand you correctly, we would also need a target interface to > tell the register cache how to map between RAWNUM and cooked REGNUM. For > example: > > /* Associate raw register number RAWNUM in GDBARCH with internal > register id REGNUM. */ > void map_raw_register (struct gdbarch *gdbarch, int rawnum, int regnum) > > Right? No. There is a many to many mapping. A cooked register might be constructed from bits (binary digits) found in both raw hardware registers and in the target memory. core-gdb would make a request to either read or write a frame register. Those methods, as implemented by the architecture, would be responsible for the scatter/gather operation required when writing/reading a cooked register. core-gdb would also assume the architecture code keeps overlapping cooked registers coherent. If register ``foo'' and ``blah'' overlap then a write to ``foo'' would immediatly be reflected in a read of ``blah''. This requirement is met by having cooked registers read/write direct to the register and memory caches. > To address that complexity, we could formalize the concept of pure > hardware descriptions, perhaps autogenerated from CGEN. They would define > canonical register names, sizes, default types, numeric IDs, default > groupings, etc. Targets would provide mappings from their numbers to > those IDs if necessary. ISAs could override register names, add > pseudo-registers, etc. That is roughly the intent. Given an ISA family it normally has a well defined register structure. The raw register buffer would contain a cannonical set of bits needed to represent the ISAs register set. The PPC, for instance, has: 32 64 bit GPRs 1024 64 bit SPRs 32 ?? bit AltavecRs All PPC ISA variants might share a common raw register cache that contained all of the above. The architecture code implementing cooked registers could determine which of the raw registers it needed to access using something like an enum. On the target side, either that enum (ppc-linux-nat.c?) or raw_register_name() (remote.c?) might be used. > These hardware descriptions could be stored in *-hwdep.c and *-hwdep.h. Some of the information can live in *-tdep.h. Other (especially the structure of a given [Gg] packet) should be hard-wired and then moved to somewhere completly outside of gdb (include/gdb/remote*blah*.h?) - never to be touched again. Eventually, however, there will probably be a shakedown and things like *-tdep.c will be broken down. Andrew