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: David Taylor <taylor at cygnus dot com>
- Subject: Re: [RFC]: internal_error should call target_terminal_ours
- From: Andrew Cagney <ac131313 at cygnus dot com>
- Date: Thu, 30 Mar 2000 10:14:07 +1000
- CC: Michael Snyder <msnyder at cygnus dot com>, gdb-patches at sourceware dot cygnus dot com
- Organization: Cygnus Solutions
- References: <200003292312.SAA26979@texas.cygnus.com>
David Taylor wrote:
>
> 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.
My only thought is that I'm not sure if target_terminal_ours() is
idenpotent. See remote.c where, due to async, it was being called
multiple times. I ended up adding code to make the functions
idenpotent. Should that code be moved to target.c?
David's made a good point. Everything goes through internal_verror().
Hey, i planned it that way :-)
Andrew