Re: [4/4] RFC: implement catch load and catch unload

[Pedro Alves <palves at redhat dot com>]

On 01/24/2012 05:07 PM, Tom Tromey wrote:
>>> +	ui_out_field_int (current_uiout, "spurious", 1);
> 
> Pedro> Do we need "spurious"?  We get the same info from neither
> Pedro> "removed" nor "added" being present.  I'm not super fond of using
> Pedro> the word "spurious" because the stop had some reason, and in my
> Pedro> mind, something spurious is something that should not have
> Pedro> happened.  But in this case, the stop means something, but we're
> Pedro> not interpreting it.
> 
> I removed it.  I also removed it from the ui_out_text call.

Thanks.

> Pedro> Maybe for "catch ...", we shouldn't report a stop in the
> Pedro> "spurious" case?
>
> We don't -- check_status_catch_solib will filter them out.

Ah, missed that.  Great.

>>> +    if (self->base.pspace != NULL && other->pspace != self->base.pspace)
>>> +      continue;
> 
> Pedro> So a consequence of this is that "catch load" is only active for
> Pedro> the inferior was current when the catchpoint was created, right?
> Pedro> Was that the intention?  If we already had itsets, we could make
> Pedro> it trigger on all inferiors by default, and then use itsets to
> Pedro> filter.
> 
> I just made it work the way other catchpoints seem to work.  They are
> also pspace-specific.  It seemed ok to do this, to me, on the theory
> that one more spot to change for itsets won't be a big burden; while on
> the other hand being different here doesn't seem beneficial.

Okay, that's reasonable.

-- 
Pedro Alves