This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Hello. > Unfortunately, GDB still insists on inserting and removing breakpoints > around each step, so things aren't quite as efficient as they could be. > I think in time even that can be fixed. Leaving breakpoints in all the time would probably greatly improve performance. This is exactly what we do when debugging ChorusOS using the Microtec XRAY debugger, at both applicative (Ethernet) and system (serial line) level. XRAY leaves the breakpoints in all the time, but requires that the debug server hides them when memory is being read. The debug servers currently forbid overwriting them, but could also transparently re-insert a breakpoint after an underlying code modification has been performed, assuming the instruction boundaries did not change. Of course, hardware breakpoints are removed or disabled systematically at each stop, but this is done by the server itself. Breakpoints are actually even automatically re-inserted by the debug server (applicative debug only) at program restart time, unless the binaries in which they are located have changed, but this is probably more questionable. The advantage is that the debugger needs to issue only one request to restart a program. This fits with the paradigm of issuing only one remote request to start execution or to get the full state after a stop. I think this optimization could be dealt-with in the target vector itself, and we will probably attempt to implement it at some point in the ChorusOS target vector code which we are developping currently. Breakpoint removes could be ignored except if GDB does not re-insert them when performing the target_resume() operation, assuming we already hide the breakpoints. BTW, since this thread was originally about optimizing stepping, ChorusOS debug servers have a special step mode called "step till next function call or return". Combined with "nexti", it is handy in order to quickly understand what a given piece of unknown code does at execution time or where it fails, by executing it from function call to function call and looking at return values. I guess such a command could be added to GDB as well (if it does not exist already, I am still relatively new to all this :-). Regards. -Adam Mirowski
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |