This is the mail archive of the
gdb-patches@sourceware.cygnus.com
mailing list for the GDB project.
Re: [RFC]: internal_error should call target_terminal_ours
- To: Michael Snyder <msnyder at cygnus dot com>
- Subject: Re: [RFC]: internal_error should call target_terminal_ours
- From: David Taylor <taylor at cygnus dot com>
- Date: Wed, 29 Mar 2000 18:12:35 -0500
- cc: gdb-patches at sourceware dot cygnus dot com
Date: Wed, 29 Mar 2000 12:10:02 -0800
From: Michael Snyder <msnyder@cygnus.com>
I just encountered a situation where internal_error was called
while the target program was running, resulting in the following:
gdb-internal-error: gdbarch: gdbarch_breakpoint_from_pc invalid
An internal GDB error was detected. This may make make further
debugging unreliable. Continue this debugging session? (y or n)
Suspended (tty input)
%] msnyder<547>%
As you can see, instead of waiting for my input, GDB suspended
because it didn't own the tty.
It's probably a bad thing (tm) to call internal_error while the
inferior is running, but in case it does happen, I wonder what
people think about the following?
I think that you're right that adding target_terminal_ours would be a
good thing. But, my inclination is to put it closer to the actual i/o
-- namely in internal_verror rather than internal_error.
Additionally, looking at internal_verror, I think that it should call
quit_force rather than calling exit -- as it is now it just abandons
the target.
Index: utils.c
===================================================================
RCS file: /cvs/src/src/gdb/utils.c,v
retrieving revision 1.5
diff -C5 -r1.5 utils.c
*** utils.c 2000/03/20 22:15:58 1.5
--- utils.c 2000/03/29 20:09:24
***************
*** 717,726 ****
--- 717,727 ----
NORETURN void
internal_error (char *string, ...)
{
va_list ap;
va_start (ap, string);
+ target_terminal_ours ();
internal_verror (string, ap);
va_end (ap);
}
/* The strerror() function can return NULL for errno values that are