From: Daniel Jacobowitz <drow@false.org>
To: Vladimir Prus <ghost@cs.msu.su>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [RFA] Implement -thread-info.
Date: Fri, 14 Mar 2008 15:08:00 -0000 [thread overview]
Message-ID: <20080314150732.GA19288@caradoc.them.org> (raw)
In-Reply-To: <fqucs4$upe$2@ger.gmane.org>
On Sat, Mar 08, 2008 at 06:54:45PM +0300, Vladimir Prus wrote:
> Vladimir Prus wrote:
>
> > I attach the revised version of the patch, including docs. Eli, is the
> > doc part OK? I intend to commit the code part in a week unless there are
> > objections.
>
> I have realized that while the patch is mostly about MI, it also
> touches generic code -- thread.c. Is that part of patch (attached again
> for convenience) OK?
>
> - Volodya
>
> * gdb.h (mi_info_threads): Declare.
I think gdbthread.h is the appropriate header for this; gdb.h is for
things using GDB_RC_OK and so forth.
> @smallexample
> - -thread-info
> + -thread-info [ @var{thread-id} ]
> @end smallexample
>
> +Reports the information about either a specific thread, if
Just "reports information", no "the".
> @@ -1055,6 +1073,7 @@ mi_cmd_list_features (char *command, char **argv, int argc)
>
> ui_out_field_string (uiout, NULL, "frozen-varobjs");
> ui_out_field_string (uiout, NULL, "pending-breakpoints");
> + ui_out_field_string (uiout, NULL, "thread-info");
>
> do_cleanups (cleanup);
>
Shouldn't this be documented too?
> +void
> +mi_info_threads (struct ui_out *uiout, int requested_thread)
Nick's right about the name of this function. print_thread_info would
be fine. info_threads_1 would be fine too - the _1 is a weird
convention that just means "the real body of info_threads", not
"info_threads for one thread". print_thread_info sounds better to me.
> /* Backup current thread and selected frame. */
> saved_frame_id = get_frame_id (get_selected_frame (NULL));
> old_chain = make_cleanup_restore_current_thread (inferior_ptid, saved_frame_id);
>
> + old_chain = make_cleanup_ui_out_list_begin_end (uiout, "threads");
> +
By overwriting old_chain, you've stopped do_cleanups from restoring
the previously selected thread.
> extra_info = target_extra_thread_info (tp);
> if (extra_info)
> - printf_filtered (" (%s)", extra_info);
> - puts_filtered (" ");
> + ui_out_field_fmt (uiout, "details", " (%s)", extra_info);
> + ui_out_text (uiout, " ");
Do you really want to give the front end " (some extra text)"? It'll
want to display this in a different column anyway. It should probably
be
ui_out_text (uiout, " (");
ui_out_field_string (uiout, extra_info);
ui_out_text (") ");
> /* That switch put us at the top of the stack (leaf frame). */
> switch_to_thread (tp->ptid);
> print_stack_frame (get_selected_frame (NULL), 0, LOCATION);
I think Nick was right about printing the frame level. It's not
necessarily going to be zero in the future. For instance, GDB might
automatically select the nearest user frame if you stop when a C++
exception is thrown, like we already do for Ada; and then we could
teach GDB not to lose the selected frame whenever it switches threads.
That wants doing anyway.
--
Daniel Jacobowitz
CodeSourcery
next prev parent reply other threads:[~2008-03-14 15:08 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-17 15:33 Vladimir Prus
2008-02-18 6:26 ` Nick Roberts
2008-02-18 7:38 ` Vladimir Prus
2008-02-18 21:45 ` Nick Roberts
2008-02-20 11:28 ` Vladimir Prus
2008-02-20 19:07 ` Eli Zaretskii
2008-02-20 19:38 ` Nick Roberts
2008-02-20 20:03 ` Vladimir Prus
2008-02-26 0:58 ` Nick Roberts
2008-02-26 1:21 ` Daniel Jacobowitz
2008-03-23 4:56 ` Nick Roberts
2008-03-23 7:38 ` Vladimir Prus
2008-03-23 16:22 ` Daniel Jacobowitz
2008-03-08 15:50 ` Vladimir Prus
2008-03-08 15:55 ` Vladimir Prus
2008-03-08 20:04 ` Nick Roberts
2008-03-10 7:59 ` Vladimir Prus
2008-03-10 9:13 ` Nick Roberts
2008-03-14 10:17 ` Vladimir Prus
2008-03-17 18:40 ` Michael Snyder
2008-03-14 15:08 ` Daniel Jacobowitz [this message]
2008-03-14 15:11 ` Daniel Jacobowitz
2008-03-14 17:04 ` Vladimir Prus
2008-03-14 18:04 ` Daniel Jacobowitz
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=20080314150732.GA19288@caradoc.them.org \
--to=drow@false.org \
--cc=gdb-patches@sources.redhat.com \
--cc=ghost@cs.msu.su \
/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