It is always better if the GDB server can do the backing up of the PC and we generally want this to happen. We don't always know how breakpoints are set when we use the Z packets to set/clear breakpoints. If there are hardware resources, then a breakpoint might get set as a hardware breakpoint and not require the backing up of the PC. Again, these are all details that the GDB server should be in charge of. If you hit a breakpoint that was set by the user, then the PC should be backed up. If you hit a hard coded breakpoint trap that was compiled in to the code, then you don't backup the PC.
I believe this support was added for one GDB server that didn't do the backing up, but I would rather not have every GDB server have to tell us that. Do you have one such GDB server that doesn't backup the PC when it should be? Greg > On Jun 5, 2014, at 1:49 PM, Ted Woodward <[email protected]> wrote: > > On some architectures, when a breakpoint is hit, the PC is set to a different > value and needs to be adjusted. This is handled in ProcesGDBRemote.cpp by the > variable m_breakpoint_pc_offset. The problem is this variable is only set via > a python target definition file. > > > > I propose extending qHostInfo to add bp_pc_decr:<offset>. > m_breakpoint_pc_offset would be set to this signed integer. > > > > Ted > > _______________________________________________ > lldb-dev mailing list > [email protected] > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev _______________________________________________ lldb-dev mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
