Re: [RFC] stepping over permanent breakpoint

[Pedro Alves <pedro@codesourcery.com>]

On Monday 16 March 2009 18:55:27, Aleksandar Ristovski wrote:
> Pedro Alves wrote:
> > On Monday 16 March 2009 17:40:49, Aleksandar Ristovski wrote:
> >> However, on systems that do not need pc adjustment after 
> >> break (like QNX) gdb will not be able to step over that 
> >> breakpoint  (...)
> > 
> >> (...) unless user explicitly sets a breakpoint on top  
> >> of it.
> > 
> > Which I think your patch breaks?  :-)
> 
> No, it doesn't, it will behave as before. Observe where is 
> the code I added, it is inside
> if (gdbarch_decr_pc_after_break (gdbarch) == 0)
> so for linux, it won't even be executed.

Not all architectures that run linux need PC adjustment.  You're
thinking x86-linux.  Anyway, I meant that you're breaking setting
a user breakpoint on top of a permanent breakpoint.  Try
setting a breakpoint with "break *int3_addr", on top
of that int3, and running to it.  When it is hit, you're moving
the PC passed it, so later calls to bpstat_stop_status like:

      /* See if there is a breakpoint at the current PC.  */
      ecs->event_thread->stop_bpstat = bpstat_stop_status (stop_pc, ecs->ptid);

... will not see the permanent breakpoint, right?

> I have tried path similar to what you suggest. It seems more 
> correct, but I would think that in addition to what you are 
> doing, it would also need a change in adjust_pc_after_break 
> to still decrement PC (to point to just-hit hardcoded 
> breakpoint). Normally, adjust_pc_after_break will (on linux) 
> miss this case and leave pc to point to instruction 
> following breakpoint instruction.

Yeah, I considered that, but I think that it is legitimate to
want to pass SIGTRAPs to the inferior, and have a SIGTRAP handler
see whatever it would see if GDB wasn't there.  This may be
useful for debugging programs that embed a gdb stub in process,
for example.  So, on decr_pc_after_break != 0 targets, I'd leave
things as they are.

Mark's point about considering a trap instruction as a normal
instruction is valid, so I'm not sure if we'd want to do this
skipping by default or not.  I'll let you guys fight
over it.  :-)

-- 
Pedro Alves