Re: [RFC] -thread-info new command

Denis PILAT
2007-04-04T14:36:42Z

Nick Roberts wrote:
> > > Actually there are currently two ways to catch an error in MI:
> > >
> > > 1) Using error () and catch_exception.
> > >
> > > 2) Using MI_CMD_ERROR and mi_error_message.
> > >
> > > The first gets caught in mi_execute_command and the error message is stored
> > > in result.message. The second goes back to captured_mi_execute_command and
> > > the error message is manually stored in mi_error_message.
> > >
> > > I think that only one method should be used and this should be the first
> > > one.
> >
> > 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.
> Does your statement defeat the logic of my suggestion?
>
> > For now can we do the minimal fix for this problem? I apologize I was
> > never clear enough about what I meant when I said that, so here's a
> > patch.
>
> Yes. I can't believe now that I didn't consider this option.
>
> > ...
> > 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.
>
> 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."?
>
>

Is there anything new about that ?
Should I re-propose a patch for -thread-info ?
--
Denis