Re: Questionable breakpoint stepping code

[Michael Snyder <msnyder at specifix dot com>]

On Fri, 2007-11-23 at 16:56 +0300, Vladimir Prus wrote:
> The infrun.c:handle_inferiour_event function has
> this code block:
> 
>         if (thread_hop_needed)
>         {
>           ........
>           remove_status = remove_breakpoints ();
>           /* Did we fail to remove breakpoints?  If so, try
>              to set the PC past the bp.  (There's at least
>              one situation in which we can fail to remove
>              the bp's: On HP-UX's that use ttrace, we can't
>              change the address space of a vforking child
>              process until the child exits (well, okay, not
>              then either :-) or execs. */
>           if (remove_status != 0)
>             {
>               /* FIXME!  This is obviously non-portable! */
>               write_pc_pid (stop_pc + 4, ecs->ptid);
>               /* We need to restart all the threads now,
>                * unles we're running in scheduler-locked mode. 
>                * Use currently_stepping to determine whether to 
>                * step or continue.
>                */
>               /* FIXME MVS: is there any reason not to call resume()? */
>               if (scheduler_mode == schedlock_on)
>                 target_resume (ecs->ptid,
>                                currently_stepping (ecs), TARGET_SIGNAL_0);
>               else
>                 target_resume (RESUME_ALL,
>                                currently_stepping (ecs), TARGET_SIGNAL_0);
>               prepare_to_wait (ecs);
>               return;
>             }
> 
> The code is a bit scary -- specifically I sure don't want GDB to mess
> with PC values like this on x86, if removing breakpoints fails in any way.
> The essential bits of this code are present as of revision 1.1 of infrun.c
> (added in 1999). 
> 
> So:
> 1. Anybody knows if this code is still needed for modern HPUX?
> 2. Can we have it wrapped in #ifdef, and if so, which one?
> 
> - Volodya

Hi Volodya, 

I think it's my code.  It's not really related specifically
to HPUX, that comment was there in the previous iteration and
I just kept it.

The several state variables with "thread_hop" as part of their
names are related to single-stepping in the presence of thread-
specific breakpoints.  They are meant to solve the problem of
what to do if you are doing a step, and you hit a thread-specific
breakpoint, but with the wrong thread.

You need to do a kind of special single-step to get past that
particular breakpoint, then return to the single-stepping
infrun state.

As for the scheduler-locking code, that pertains to a 
different but not wholly unrelated functionality (set 
scheduler-locking), which affects which threads can run
at which times.

As for your last question, no, I don't believe we approve
of ifdefs...

Cheers,
Michael