Date: Fri, 10 Mar 2000 12:40:47 -0500 (EST)
Message-Id: <200003101740.MAA22057@indy.delorie.com>
From: Eli Zaretskii <eliz AT delorie DOT com>
To: djgpp AT delorie DOT com
CC: Robert S Whitlock <roberts DOT j DOT whitlock AT juno DOT com>
In-reply-to: <20000309.144953.-398953.1.roberts.j.whitlock@juno.com> (message
	from Robert S Whitlock on Thu, 9 Mar 2000 14:49:44 -0500)
Subject: Re: Is dual monitors necessary?
References:  <20000309 DOT 144953 DOT -398953 DOT 1 DOT roberts DOT j DOT whitlock AT juno DOT com>
Reply-To: djgpp AT delorie DOT com
Errors-To: dj-admin AT delorie DOT com
X-Mailing-List: djgpp AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk


> But the program I need to debug is a graphics app, and whenever I
> set a breakpoint after the program switched to graphics mode, the
> breakpoint works fine.... but the monitor remains in that graphics mode
> and not the one gdb is using. I can type "shell edit" and it will switch
> back to desktop and edit will be there and that's just fine and dandy,
> and when I exit from edit the graphics mode screen comes back again and
> that's fine, but I can never get to see the actual gdb prompt.

GDB currently only supports graphics modes which are known to your
system BIOS.  Usually, this means only the standard VGA modes up to
and including mode 13h.  The console I/O routines used by GDB 4.18
work in such a way that you should be able to see GDB's prompt and
other output in the supported video modes.  If your program uses one
of these modes, but you cannot see GDB's prompt, please tell the
details; it works for me.

If your program uses SVGA or VESA modes, you will have to try harder.
The DJGPP FAQ list describes the various possibilities in section
12.3, which see.  Your trick with "shell edit" hints that there may be
one other, simpler possibility: write a simple program that switches
the screen between text and graphics mode, and then invoke that
program via the "shell" command whenever you need to communicate with
GDB.