[PATCH] Fix for follow-fork: followed child doesn't stop

[Pedro Alves]

On 06/13/2014 02:06 AM, Breazeal, Don wrote:
> 
> Hi Pedro,
> Thanks for clarifying this for me.

Thanks for working on this.

> 
> On 6/6/2014 4:34 AM, Pedro Alves wrote:

> Set the cloned breakpoint as disabled from the moment it is created.
> This is done by modifying clone_momentary_breakpoint to take an
> additional argument, LOC_ENABLED, which is used as the value of the
> bp_location->enabled member.  The clone must be disabled at that point,
> rather than later, because clone_momentary_breakpoint calls
> update_global_location_list, which will treat the clone as a duplicate
> of the original breakpoint if it is enabled.
> 
> All the calls to clone_momentary_breakpoint had to be modified to pass
> '1' or '0'.  I looked at implementing an enum for the enabled member,
> but concluded that readability would suffer because there are so many
> places it is used as a boolean, e.g. "if (bl->enabled)".
> 
> In follow_inferior_reset_breakpoints, the clone is set to enabled once
> it has been associated with the child process.  With this, the
> bp_location 'inserted' member is maintained correctly throughout the
> follow-fork procedure and the behavior is as expected.
> 
> The same treatment is given to the exception_resume_breakpoint when
> following a fork.
> 
> Testing:
> 
> Ran 'make check' on Linux x64.
> 
> Along with the fix above, the coverage of the follow-fork test
> gdb.base/foll-fork.exp was expanded to:
> 
> 1) cover all the combinations of values for follow-fork-mode and
> detach-on-fork
> 
> 2) make sure that both user breakpoints and single-step breakpoints are
> propagated correctly to the child
> 
> 3) check that the inferior list has the expected contents after
> following the fork.
> 
> 4) check that unfollowed, undetached inferiors can be resumed.
> 

Excellent.

This version is OK.

Thanks!

-- 
Pedro Alves