This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFA: fix gdb_assert caused by 'catch signal ...' and fork


On 05/10/2013 11:14 PM, Philippe Waroquiers wrote:
> On Fri, 2013-05-10 at 18:18 +0100, Pedro Alves wrote:
>> On 05/10/2013 05:39 PM, Doug Evans wrote:
>>> However, there's nothing in "bp_loc_other" that says we should always
>>> continue there.
>>> Other breakpoint kinds are marked bp_loc_other too.
>>
>> The other breakpoint kinds (software watchpoints, catchpoints,
>> tracepoints) don't require detaching.  The state of bp_loc_other
>> breakpoints, at least at present, is always on the GDB side.
>> Detaching is required for those breakpoints that is assumed
>> get auto-cloned by the target/kernel to forked children.
>>
>>> Plus avoiding calling remove_breakpoint_1 feels like working around the problem.
>>> This doesn't feel like the right fix.
>>
>> GDB doesn't have an inferior or any other state corresponding
>> to the process whose breakpoints are being detached.
>>
>> An alternative I imagine would be something like adding
>> "detach breakpoint" target methods (and bl->owner->ops->detach_location,
>> etc.) and call that instead of remove_breakpoint_1, though it
>> seems like we'd get the same result (with the present state).  But
>> I won't object to trying that.
> I do not master much of breakpoint.h/.c but it looks to
> me that this implies to add quite some code which will
> at the end either do nothing (for bp_loc_other) or
> call remove_breakpoint_1 (for others).

Not exactly remove_breakpoint_1, but something like it, that
ends up calling (a new) target_detach_breakpoint.

> What would be the advantages of the detach_breakpoint
> and detach_location target methods ?

It'd be one way forward if we actually needed to
detach some kind of catchpoint, while not others.

Note the idea wasn't that much cooked, I'd leave that to
whoever attempts to implement it.  It could end up being
the target method wouldn't be necessary.  The gist
would be to use breakpoint_ops dispatching somehow instead
of explicit type checks.

Or maybe some other deeper design change would be better.
Changing how core gdb reacts to forks throughout, making
it have an inferior for the new fork sooner comes to mind.

I don't have a substantially formed idea of what that would
be the ideal design, and I can't afford spending hours/days
investigating this myself at the moment, unfortunately.

> As long as there is no need (yet) for a different "detach"
> behaviour depending on specialised bp_location, it looks
> to me that the single "if" is simpler and corresponds to
> the description of detach_breakpoints in breakpoint.h.

Right, that was my reasoning for suggesting going with
the location type originally.

-- 
Pedro Alves


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]