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] |
> Even consider making everything a pseudo so that you know exactly what >> you have at any stage. >> > > > Hmm, I think this is effectively what I have. See the code below (which is > very much a work-in-progress..., so don't even expect it to compile ;-) Even more ruthless. Try a register layout of: -- raw normal r0..r15 raw someothers raw floats raw bank r0..r15 raw still more -- pseudo r0..r15 mapped onto either normal or banked pseudo floats mapped onto floats and so on, for instance, explict register names to identify normal and banked r0. -- which completly separates the raw and pseudo registers. The function register_name() becomes: if regnum < NUM_REGS return ""; else return yourtable[regnum - NUM_REGS]; In an ideal world, I'd be changing register_{read,write} to take a ``struct pseudoreg *'' and regcache_{read,write} to take a ``struct rawreg *''. That way it would be clear what is going on. I can but dream! I'm still trying to bury registers[] -) >> > I can make my arm_register_read function correctly remap the register >> > numbers, but then I run into the problem that REGISTER_RAW_SIZE is used >> > both above and below the regcache. > >> >> I don't understand why this is a problem. I think a register (pseudo or >> raw) should have only one size (c.f. my register_size() patch). > > > However, in this situation, > pseudo_rengo("r0") != regcache_regno("r0"), yet we effectively have > > REGSITER_RAW_SIZE (pseudo_regno ("r0")) > and > REGISTER_RAW_SIZE (regcache_regno ("r0")) Sorry, I still don't understand. Given pseudo-registers, the name of the function ``register_raw_size'' is definitly overloaded. However, per the patch very recently committed, the norm should now be: register_raw_size() == register_virtual_size() == TYPE_LENGTH (register_virtual_type()) (which makes them all badly named :-) > ! /* We have more registers than the disassembler as gdb can print the > ! value of special registers as well. It can also display the > ! contents of banked registers if these are available from the > ! inferior. > ! > ! Depending on the architecture, ARM processors have up to 31 integer > ! registers, but these are banked so that only 16 are visible at any > ! one time. The layout of the table is complicated by the fact that > ! the ordering must match that used by the compiler to generate > ! stabs/dwarf entries, so we put the banked registers first, even > ! though we implement some of them as pseudos (mapping onto the > ! correct bank entry for the current mode). A debug record entry may > ! contain: > ! > ! 0-15 for the integer registers r0-r15, > ! 16-23 for the FPA registers f0-f7, > ! 32-63 for the VFP registers s0-s31. This restriction doesn't exist. Your architecture has complete control over how debug register numbers are represented internally. For instance, STABS_REG_TO_REGNUM() can be used to completly map the above numbers onto pseudo-registers. Again, in an ideal world, I'd try to change these functions to return a ``struct pseudoreg *''. That would make it clear which side of the fence they sit on :-) > ! Which leaves a gap of 8 registers in the numbering space: we put > ! the cpsr, spsr (x5), fpsr and fpcr registers in this space, though > ! not all of these will always be available. None of these registers > ! will have debug table entries. [XXX-rwe 20020511 At least, I don't > ! think so]. > ! > ! The general register names are overwritten by whatever is being > ! used by the disassembler at the moment. We also adjust the case of > ! cpsr and fps. > ! > ! Note, the ordering of registers in the regcache is entirely > ! different, since we don't want the pseudo registers in that. The > ! mapping tables follow. */ (I think I remember what you wanted me to document ....) enjoy, Andrew
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |