On Thursday 14 January 2010, yintang gu wrote: > > >Hmm ... is this a bug you've observed, or is this something > >you've wondered after poking through the code? > > >I recall setting breakpoints through the Tcl interface and > >having them behave correctly. Haven't tried to do that any > >time recently, though. And I could believe there's a bit > >of a semantic conflict between debug via GDB and via Tcl; > >not one we want, of course!! > > > > I found that the breakpoint and step operations take no effect when debugging > with GDB > while everything is OK in TCL interfaces.
That's pretty odd... I have no idea why they are set up to act differently. > Then I found the problem after poking through the code. > The problem is resolved when I modified gdb_step_continue_packet() in > gdb_server.c by calling > target_resume() with handle_breakpoints=true which is false originally. But > I'm not sure weather > the modification is correct because we can see from the code below that the > designer had done that > in special purpose. > > > retval = target_resume(target, current, address, 0, 0); > /* resume at current address, don't handle breakpoints, not > debugging */ Yeah, that's kind of puzzling. GDB says not to handle breakpoints, so the target resumes without handling breakpoints -- as requested. And then GDB misbehaves??? Evidently "handle" is being used to mean something pretty odd. (Just like "debugging", for that matter...) I'll hope someone else chimes in with some insights here. This kind of needs to get sorted before 0.4 freezes. - Dave _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
