Re: [rfc] Problems with software single-step and SPU breakpoints during fork

[Pedro Alves <pedro at codesourcery dot com>]

On Monday 21 June 2010 20:30:38, Ulrich Weigand wrote:
> +      if (singlestep_breakpoints_inserted_p)
> +       {
> +         /* Pull the single step breakpoints out of the target. */
> +         remove_single_step_breakpoints ();
> +         singlestep_breakpoints_inserted_p = 0;
> +       }
> +
>        /* Immediately detach breakpoints from the child before there's
>          any chance of letting the user delete breakpoints from the
>          breakpoint lists.  If we don't do this early, it's easy to

I think you should unpatch the single-step breakpoints from
both parent and child.  If you set detach-on-fork off, and then
resume the child, won't it trip on the left over software single-step
breakpoint?  Oh, I guess that happens to not be a problem on the SPU,
as both parent and child access the same SPU contexts, so removing
the breakpoints from the parent also removed it from the child, though it
looks like a problem on regular software single-step archs, like linux
ARM or MIPS.  Unfortunately, single step breakpoints are still using the
deprecated_insert_raw_breakpoint mechanism and don't appear in the
breakpoints/locations lists, otherwise, the "Immediately detach
breakpoints" bit below would also take care of it ...

> @@ -3314,6 +3321,8 @@ handle_inferior_event (struct execution_
>           reinit_frame_cache ();
>         }
>  
> +      singlestep_breakpoints_inserted_p = 0;
> +
>        stop_pc = regcache_read_pc (get_thread_regcache (ecs->ptid));

Hmm, what is actually clearing single_step_breakpoints[0|1]?
Are things just appearing to work correctly because 
the single_step_breakpoints[1] slot happens to be free on next
single-step resume?  (actually, don't we have the same problem
with process exits while single-step breakpoints are inserted?
that's a rare event, but possible.)

(software single-step and these related globals obviously
need TLC for multi-process/non-stop)

On Monday 21 June 2010 20:30:38, Ulrich Weigand wrote:
> The second problem is related to detach_breakpoints.  This routine is called
> at fork time and pulls all breakpoints out of the child process, assuming
> that they were copied by fork.
> 
> While this is certainly true for PPU side breakpoints, it is not true for SPU
> side breakpoints.  fork will clone the SPU context file descriptors, so that
> all the existing SPU contexts are in accessible in the new process.  However,
> the contents of the SPU contexts themselves are not cloned.  Therefore the
> effect of detach_breakpoints is to remove SPU breakpoints from the original
> SPU context's local store ...
> 
> As a workaround, I'm now installing an SPU gdbarch_memory_remove_breakpoint
> routine that simply does nothing if called from detach_breakpoints.  This
> case is detected if the PID we are asked to remove this breakpoint from
> (i.e. ptid_get_pid (inferior_ptid)) is different from the PID of the current
> inferior (i.e. current_inferior()->pid).
> 
> Any comments?  I'd appreciate any suggestions how to fix this in a
> cleaner way ..

I think doing something clean would entail teaching gdb core
about SPU/PPU's multiple address spaces.

detach_breakpoints itself is a hack, so I don't have a problem
with going with this approach meanwhile.

-- 
Pedro Alves