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