From: Tom Tromey <tromey@redhat.com>
To: Pedro Alves <palves@redhat.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [4/4] RFC: implement catch load and catch unload
Date: Tue, 24 Jan 2012 17:22:00 -0000 [thread overview]
Message-ID: <m3lioxc9m2.fsf@fleche.redhat.com> (raw)
In-Reply-To: <4F19B998.2030308@redhat.com> (Pedro Alves's message of "Fri, 20 Jan 2012 18:59:36 +0000")
>> + 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
next prev parent reply other threads:[~2012-01-24 17:07 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-19 21:03 Tom Tromey
2012-01-19 22:04 ` Eli Zaretskii
2012-01-20 15:12 ` Tom Tromey
2012-01-20 17:40 ` Pedro Alves
2012-01-24 17:31 ` Tom Tromey
2012-01-24 19:40 ` Pedro Alves
2012-01-20 17:44 ` Yao Qi
2012-01-20 19:45 ` Pedro Alves
2012-01-24 17:07 ` Tom Tromey
2012-01-24 17:28 ` Marc Khouzam
2012-01-24 18:25 ` Tom Tromey
2012-01-24 18:32 ` Marc Khouzam
2012-01-24 19:15 ` Tom Tromey
2012-01-24 20:36 ` Marc Khouzam
2012-01-24 17:22 ` Tom Tromey [this message]
2012-01-24 19:17 ` Pedro Alves
2012-01-24 22:11 ` Tom Tromey
2012-01-25 11:06 ` Regression for gdb.mi/mi-nsmoribund.exp [Re: [4/4] RFC: implement catch load and catch unload] Jan Kratochvil
2012-01-25 11:18 ` Regression for gdb.base/solib-disc.exp [Re: Regression for gdb.mi/mi-nsmoribund.exp] Jan Kratochvil
2012-01-25 17:09 ` Tom Tromey
2012-01-25 17:27 ` Jan Kratochvil
2012-01-25 16:20 ` Regression for gdb.mi/mi-nsmoribund.exp [Re: [4/4] RFC: implement catch load and catch unload] Tom Tromey
2012-02-20 8:28 ` [commit] catch-load.exp: Fix racy FAILs " Jan Kratochvil
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m3lioxc9m2.fsf@fleche.redhat.com \
--to=tromey@redhat.com \
--cc=gdb-patches@sourceware.org \
--cc=palves@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox