From: Nick Roberts <nickrob@snap.net.nz>
To: Joel Brobecker <brobecker@adacore.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [PATCH] New annotation for threads
Date: Thu, 01 May 2008 23:31:00 -0000 [thread overview]
Message-ID: <18458.21177.959458.278174@kahikatea.snap.net.nz> (raw)
In-Reply-To: <20080501181758.GD3801@adacore.com>
> > > How about creating a new observer for new_threads events instead of
> > > specifically calling an annotation function from "add_thread"? Seems
> > > much cleaner that way.
> >
> > I'm not sure what you mean, or how I would register such an observer.
> > All other annotations are done this way and, unlike MI, annotations don't
> > have their own interpreter but just mark up CLI.
>
> The observers are documented in doc/observer.texi. Basically, you need
> to do the following:
>
> static void
> annotate_new_thread (struct thread_info *thread)
> {
> /* Your annotation here. */
> }
>
> And then attach this observer to the new_thread event using:
>
> observer_attach_new_thread (annotate_new_thread);
Yes, I can see how observers work. I sent a patch earlier for thread-changed
and frame-changed events.
> All this can be done inside annotate.c.
Where in annotate.c? It can't be in _initialize_annotate because that only
gets called at startup and the annotation level can be changed with the
"set annotate" command (which is also why deprecated_delete_breakpoint_hook
and deprecated_modify_breakpoint_hook shouldn't be set there).
None of the other annotations are implemented using observers and this patch is
just meant as a stop gap before migrating fully to MI, not as a permanent
feature.
I therefore ask to commit this patch as is on the grounds that:
1) Emacs is the only application likely to use it.
2) All other users will be unaffected by this change.
--
Nick http://www.inet.net.nz/~nickrob
next prev parent reply other threads:[~2008-05-01 23:31 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-18 16:06 Nick Roberts
2008-04-29 4:47 ` Joel Brobecker
2008-04-29 14:19 ` Nick Roberts
2008-05-01 18:18 ` Joel Brobecker
2008-05-01 18:44 ` Daniel Jacobowitz
2008-05-01 23:31 ` Nick Roberts [this message]
2008-05-01 23:37 ` Joel Brobecker
2008-05-02 0:07 ` Nick Roberts
2008-05-02 5:50 ` Joel Brobecker
2008-05-02 10:41 ` Eli Zaretskii
2008-05-17 15:51 ` Nick Roberts
2008-05-17 19:15 ` Stan Shebs
2008-05-17 21:18 ` Eli Zaretskii
2008-05-18 3:20 ` Bob Rossi
2008-05-18 9:11 ` Bob Rossi
2008-05-18 17:44 ` Eli Zaretskii
2008-05-19 8:48 ` Joel Brobecker
2008-05-19 9:09 ` Nick Roberts
2008-05-19 9:44 ` Eli Zaretskii
2008-05-19 12:39 ` Nick Roberts
2008-05-19 13:23 ` Eli Zaretskii
2008-05-20 15:27 ` Joel Brobecker
2008-05-20 16:10 ` Nick Roberts
2008-05-20 16:43 ` Nick Roberts
2008-05-20 18:09 ` Joel Brobecker
2008-05-21 3:55 ` Nick Roberts
2008-05-21 7:22 ` Joel Brobecker
2008-05-20 22:21 ` Eli Zaretskii
2008-05-20 22:54 ` Joel Brobecker
2008-05-21 3:26 ` Eli Zaretskii
2008-05-21 9:33 ` Joel Brobecker
2008-05-21 15:11 ` Nick Roberts
2008-05-21 15:14 ` Joel Brobecker
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=18458.21177.959458.278174@kahikatea.snap.net.nz \
--to=nickrob@snap.net.nz \
--cc=brobecker@adacore.com \
--cc=gdb-patches@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