This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [4/4] RFC: implement catch load and catch unload
- From: Tom Tromey <tromey at redhat dot com>
- To: Pedro Alves <palves at redhat dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Tue, 24 Jan 2012 10:07:33 -0700
- Subject: Re: [4/4] RFC: implement catch load and catch unload
- References: <m3d3afxweq.fsf@fleche.redhat.com> <4F19B998.2030308@redhat.com>
>> + 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.
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.
>> - if (shlib_event)
Pedro> The shlib_event local should be removed then.
Thanks, I did this. I fixed up the other little details too.
>> + 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.
Tom