Re: [RFC] -thread-info new command

Nick Roberts
2007-04-10T21:54:57Z

> > 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.