From: Andrew Cagney <ac131313@redhat.com>
To: Alain Magloire <alain@qnx.com>
Cc: gdb@sources.redhat.com
Subject: Re: Event notification (was Re: GDB/MI lawyer for Thread Creation)
Date: Wed, 07 May 2003 16:16:00 -0000 [thread overview]
Message-ID: <3EB93140.30803@redhat.com> (raw)
In-Reply-To: <200305071519.LAA00443@node1.ott.qnx.com>
> I went digging in the old email exchanges with kseitz ....
> And yes this is what I'm looking for
>
> one nitpicking:
>
> - the event notifications mechanism seem to be for side effects, for example
> setting a breakpoint via CLI, notification is sent informing of the side effect.
> Or assigning statements having side effects.
>
> It does not seem to address "pure" async event. Threads creation/destruction,
> and loading of shared libs are two examples that spring to mind about the need
> of notification when the inferior is still running.
>
> It those cases, I would say that sending an OOB instead of async-notify is more
> appropriate.
Hmm, makes sense - a real rationale. Anyone else have comments?
Want to re-word the MI doco so this is clearer?
> Questions:
> Will kseitz_interps-20020528-branch be merge to the main trunk?
> Any ETA ?
The branch contains a lot of stuff, but importantly prototypes for two
new features:
- interps command
- breakpoint events
The interps feature is now implemented in the mainline. The breakpoint
stuff has't been done. One missing bit of the framework needed for
that feature - observer.[hc] - was recently added by Joel though.
> I'm exited about this, it brings be closer in providing a more powerfull/flexible
> gui debugger.
Andrew
next prev parent reply other threads:[~2003-05-07 16:16 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-05-06 21:31 GDB/MI lawyer for Thread Creation Alain Magloire
2003-05-06 21:51 ` Andrew Cagney
2003-05-07 15:19 ` Event notification (was Re: GDB/MI lawyer for Thread Creation) Alain Magloire
2003-05-07 16:16 ` Andrew Cagney [this message]
2003-05-07 18:56 ` Alain Magloire
2003-05-16 3:14 ` Andrew Cagney
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=3EB93140.30803@redhat.com \
--to=ac131313@redhat.com \
--cc=alain@qnx.com \
--cc=gdb@sources.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).