This is the mail archive of the gdb@sourceware.cygnus.com mailing list for the GDB project. See the GDB home page for more information.


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

RE: Breakpoints in GDB


Thanks, that explains the problem very well.

> 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?

This almost certainly breaks calling functions in the debuggee (I don't
know how well calling functions works without the change on ppc-eabi
targets though).
A better solution would be to define CALL_DUMMY_BREAKPOINT_OFFSET as 48,
which is the actual location of the breakpoint instruction in the call dummy.

> 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?

-- 
Peter Schauer			pes@regent.e-technik.tu-muenchen.de