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