This is the mail archive of the gdb@sourceware.cygnus.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]

Re: GDB Proto: Draft revised spec...


> Note the WDB protocol (used by vxWorks) specification also leaves
> details such as which registers are in each reg set, and the offsets
> of registers within a set are left unspecified.  So, if the RDP spec
> ends up omitting similar details, it won't be the only one.

I do not recommend emulating this approach. It is a major long-term annoyance.

Those of us at WRS who have had to deal with the register list mechanisms
are not at all happy with the current state of things. We are probably going
to be stuck with a central database of register information maintained on
the host in order to deal with the problem in a backwards-compatible way.

The remote protocols I saw when I was at Green Hills all suffered from the
same problems. Eventually I got disgusted with the whole "we just know"
attitude of hard-coding things, and began pitching the idea of having a
compressed text block of environ strings on each target. When the host
and target connect up, we dump the environment block and search in there
for everything.

Originally I thought of this as just a way to know which registers were
present on a given target and what numbers should be used for each one,
but over time I've come to believe that it isn't too much more expensive
to represent the types of the registers as well, so that you know from
looking at the environment block
	- the list of register names & numbers, broken down into groups
	- how many bits wide each register is
	- a type designator to enable better value formatting if known to GDB

Take m68k for example:

 {"d0", "d1", "d2", "d3", "d4", "d5", "d6", "d7", \
  "a0", "a1", "a2", "a3", "a4", "a5", "fp", "sp", \
  "ps", "pc",  \
  "fp0", "fp1", "fp2", "fp3", "fp4", "fp5", "fp6", "fp7", \
  "fpcontrol", "fpstatus", "fpiaddr", "fpcode", "fpflags" }

REG_SETS=data,addr,ctrl,fpu
REG_data=d0-7,0,32
REG_addr=a0-7,8,32
REG_ctrl=ps,16,16;pc,17,32
REG_fpu=fp0-7,18,80;fpcontrol,26,32;fpstatus,27,32;fpiaddr,28,32;fpcode,29,32;fpflags,30,32

This is all off the top of my head, so I left out the type designator and
guessed that the fpu control regs were all 32 bits, but I think you get the
idea...

-- 
Todd Whitesel
toddpw @ wrs.com

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