This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFC] -thread-info new command
- From: Daniel Jacobowitz <drow at false dot org>
- To: Nick Roberts <nickrob at snap dot net dot nz>
- Cc: Denis PILAT <denis dot pilat at st dot com>, gdb-patches <gdb-patches at sourceware dot org>
- Date: Tue, 10 Apr 2007 10:53:46 -0400
- Subject: Re: [RFC] -thread-info new command
- References: <45FE9E6A.3030906@st.com> <17919.15500.439138.600411@kahikatea.snap.net.nz> <17919.20575.286260.761826@kahikatea.snap.net.nz> <20070320031409.GA7336@caradoc.them.org> <17919.21588.93918.661753@kahikatea.snap.net.nz> <17921.40699.742164.983281@kahikatea.snap.net.nz> <20070327195414.GN28164@caradoc.them.org> <17929.36288.344474.485310@farnswood.snap.net.nz>
On Wed, Mar 28, 2007 at 09:33:52AM +1200, Nick Roberts wrote:
> > Once upon a time there were supposed to be more things using "libgdb"
> > - these gdb_* wrapper functions. It didn't come to pass.
>
> I thought the gdb_* wrapper function were just designed to catch exceptions.
They were designed to isolate users of libgdb from GDB's internal
exception handling mechanism, which is basically the same thing.
> 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.
> > 2007-03-27 Daniel Jacobowitz <dan@codesourcery.com>
> >
> > * breakpoint.c (gdb_breakpoint_query): Really return an
> > enum gdb_rc.
> > (gdb_breakpoint): Likewise.
> > * thread.c (do_captured_list_thread_ids): Likewise.
> > (do_captured_thread_select): Likewise.
> > * mi/mi-main.c (mi_cmd_thread_select): Expect an enum gdb_rc.
> > (mi_cmd_thread_list_ids): Remove bogus initialization.
>
> 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. So
I checked it in the way it is. We need to cut down on the number of
exception handling interfaces, but I'm not going to tackle that one
today!
> 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.
--
Daniel Jacobowitz
CodeSourcery