Execution pipeline

Execution pipeline

[Pierre Saucourt-Harmel (r54698)]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2385 bytes --]

Hi.
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
side).
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
arm-tdep.c 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
yet.
Thanks for your help.
Pierre.
------------------clip--------------------------
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;
    }
  else
    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];
}
-----------------clip----------------------------
 

Execution pipeline (2nd)

[Pierre Saucourt-Harmel (r54698)]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2611 bytes --]

Hi.
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.
Pierre.
 
Hi.
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
side).
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
arm-tdep.c
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
yet.
Thanks for your help.
Pierre.
------------------clip--------------------------
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;
    }
  else
    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];
}
-----------------clip----------------------------
 

Re: Execution pipeline (2nd)

[Andrew Cagney]

"Pierre Saucourt-Harmel (r54698)" wrote:
> 
> Hi.
> 
> 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 ?

No.  GDB assumes that the target it is looking at has synchronised (a
PPC term) its self draining all pipelines.

	Andrew