Execution pipeline (2nd)

Pierre Saucourt-Harmel (r54698) pierre.saucourt-harmel@motorola.com
Fri Feb 16 01:16:00 GMT 2001

Any idea if yes or no, GDB v5.0 is able to take into account the execution
pipeline of a processor, such as the ARM7T, when this pipeline has consequences
on the external programing model of the processor ?
Thanks in advance.
I am working with the gdb-5.0 for cross debugging an ARM program running
on an ARM simulator. Communication between ARM simulator and gdb-5.0 is
specific and wrapping code were added on both sides (a new remote-simu.c
file on the gdb-5.0 side and specific gdb server code on the ARM simulator
As the ARM processor has a pipeline (two levels), the current instruction
address differs from the pc register (r15). The ARM simulator respects
the pipeline behavior, differentiating the current instruction address
from the pc register.
To have a correct gdb behavior, the gdb server has to put the current
instruction address value when it sends the pc register to gdb. It is not
very realistic when I watch the r15 register in gdb.
If the gdb server put the real r15 value (i.e. the current instruction
address + 8), the gdb behavior is erroneous.
Do you know if and how gdb-5.0 can take the processor pipelining into
account ?
Moreover, tracing the gdb-5.0 code, I probably found two bugs in the
file, when code loops across tables of NUM_REGS registers. In two cases
( check_prologue_cache () and save_prologue_cache () ),
the loops go after the last element of the register tables. As I don't
have a more recent version of gdb-5.0, I don't know if they were fixed
Thanks for your help.
static int
check_prologue_cache (struct frame_info *fi)
  int i;
  if (fi->pc == prologue_cache.pc)
      fi->framereg = prologue_cache.framereg;
      fi->framesize = prologue_cache.framesize;
      fi->frameoffset = prologue_cache.frameoffset;
      for (i = 0; i <= NUM_REGS; i++)
        fi->fsr.regs[i] = prologue_cache.fsr.regs[i];
      return 1;
    return 0;
/* Copy the prologue information from fi to the prologue cache. 
static void
save_prologue_cache (struct frame_info *fi)
  int i;
  prologue_cache.pc = fi->pc;
  prologue_cache.framereg = fi->framereg;
  prologue_cache.framesize = fi->framesize;
  prologue_cache.frameoffset = fi->frameoffset;
  for (i = 0; i <= NUM_REGS; i++)
    prologue_cache.fsr.regs[i] = fi->fsr.regs[i];

More information about the crossgcc mailing list