Breakpoints in GDB

Jay Monkman jmonkman@frasca.com
Thu Aug 20 06:20:00 GMT 1998


Peter Schauer (Peter.Schauer@regent.e-technik.tu-muenchen.de) wrote:
> You don't tell us how your GDB was configured and which version of GDB
> you are using.
> 
Sorry, it's version 4.17 and the target is ppc-rtems-eabi or ppc-eabi, I
forget which exactly.

> Did you find out where GDB is changing the value of the PC to LR ?
> I am unable to figure out where this could happen in a rs6000/powerpc
> configured gdb-4.17.
> 
In normal_stop(), it calls a macro POP_FRAME that is defined as pop_frame()
in rs6000-tdep.c. On line 634
of that file it sets PC_REGNUM to lr.

> How is TEXT_SEGMENT_BASE defined for your configuration ?
> 
It's defined as 1.

Now, I actually fixed my problem, I think. My problem didn't have anything
to do with hardware breakpoints. It
had to do with the location of the stack in relation to the text section (or
program counter). I didn't have any
problem using breakpoints when running my program from ram. But when I tried
running from FLASH memory,
I ran into the problem. My stack is around address 0xff002000, ram starts at
0x0, and flash is at 0xfff00000.
So, when I'm running code from ram, the PC < SP, but when running from
FLASH, the PC > SP. I don't think
that should matter, but in infrun.c, line 1178 is:

      if (PC_IN_CALL_DUMMY (stop_pc, read_sp (), FRAME_FP (get_current_frame
()))

	  && !step_range_end)



PC_IN_CALL_DUMMY is defined in tm-ppc-eabi.h
as something like:

	#define PC_IN_CALL_DUMMY(stop_pc, stop_sp, fp) \
		(stop_sp < stop_pc)

So when I execute code from FLASH, this is true, and caused my problem. What
I did to fix it was define
CALL_DUMMY_BREAKPOINT_OFFSET as 0. I don't know if this breaks anything else
though. Is there 
a better way of fixing it? Maybe changing the PC_IN_CALL_DUMMY macro?





More information about the Gdb mailing list