From: Nick Roberts <nickrob@snap.net.nz>
To: Daniel Jacobowitz <drow@false.org>
Cc: Denis PILAT <denis.pilat@st.com>,
gdb-patches <gdb-patches@sourceware.org>
Subject: Re: [RFC] -thread-info new command
Date: Tue, 10 Apr 2007 21:54:00 -0000 [thread overview]
Message-ID: <17948.1808.87473.108774@farnswood.snap.net.nz> (raw)
In-Reply-To: <20070410145346.GC30086@caradoc.them.org>
> > Does your statement defeat the logic of my suggestion?
> Honestly, I'm not sure. I looked at your patch again; I don't think I
> understand why you want to change gdb_breakpoint.
So the errors get caught in mi_execute_command (since they are not front end
errors) as I've already said.
> > I think that the do_captured_* functions should have return type enum
> > gdb_rc not int.
>
> Yes, it would be nice - but unfortunately they can't, since
> catch_exceptions_with_msg requires the function to return an int.
We must be reading a different book:
/* Print a list of thread ids currently known, and the total number of
threads. To be used from within catch_errors. */
static int
do_captured_list_thread_ids (struct ui_out *uiout, void *arg)
{
...
do_cleanups (cleanup_chain);
ui_out_field_int (uiout, "number-of-threads", num);
return GDB_RC_OK;
}
I think your ChangeLog entry should have read:
* thread.c (gdb_list_thread_ids): Likewise.
(gdb_thread_select): Likewise.
>...
> > More generally though, re my patch, does make_cleaunp work on
> > deprecated_set_gdb_event_hooks? Do you think it's a good idea to
> > distinguish between user errors, e.g, "No stack." and front end errors,
> > e.g, "-var-delete: Usage: [-c] EXPRESSION."?
>
> It would be nice if front ends could separately detect "the front end
> has done something silly" -I do not think it's a big deal, but it
> might make correct front ends easier to write, and that would help
> everybody.
It would also help stop bugs in front ends from being reported on the gdb
mailing list.
--
Nick http://www.inet.net.nz/~nickrob
next prev parent reply other threads:[~2007-04-10 21:54 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-03-19 14:30 Denis PILAT
2007-03-20 1:44 ` Nick Roberts
2007-03-20 3:09 ` Nick Roberts
2007-03-20 3:14 ` Daniel Jacobowitz
2007-03-20 3:26 ` Nick Roberts
2007-03-21 21:09 ` Nick Roberts
2007-03-22 4:35 ` [RFC] gdb_breakpoint " Nick Roberts
2007-03-27 19:54 ` Daniel Jacobowitz
2007-03-27 21:36 ` Nick Roberts
2007-04-04 14:36 ` Denis PILAT
2007-04-10 15:14 ` Daniel Jacobowitz
2007-04-10 14:53 ` Daniel Jacobowitz
2007-04-10 21:54 ` Nick Roberts [this message]
2007-04-10 22:04 ` Daniel Jacobowitz
2007-04-11 1:16 ` Nick Roberts
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=17948.1808.87473.108774@farnswood.snap.net.nz \
--to=nickrob@snap.net.nz \
--cc=denis.pilat@st.com \
--cc=drow@false.org \
--cc=gdb-patches@sourceware.org \
/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