Date: Fri, 19 May 2000 08:28:53 -0400 (EDT) Message-Id: <200005191228.IAA23653@indy.delorie.com> From: Eli Zaretskii To: "Barry" CC: djgpp AT delorie DOT com In-reply-to: (barryem AT yahoo DOT com) Subject: Re: Debugging graphics References: Reply-To: djgpp AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: djgpp AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk > From: "Barry" > Newsgroups: comp.os.msdos.djgpp > Date: Thu, 18 May 2000 13:05:26 -0500 > > I've recompiled but that doesn't change anything. The program runs > ok without the debugger. I've also tried using gdb and it works > fine in gdb but I can't see anything once it goes into graphics > mode since I can't figure out how to get gdb to do screen swapping > if it will do it. GDB 4.18 supports only those graphics mode which your system BIOS supports. That means video modes 0-13h. If your program uses an SVGA mode not supported by the system BIOS, GDB will not support it. (Versions of GDB before 4.18 didn't even support standard BIOS modes.) Even if you do use one of the standard modes, debugging such a program in GDB is awkward: the graphics display scrolls off the screen as you type commands and get responses from GDB. For full-fledged debugging of graphics programs, you need to use RHIDE. It has code to switch between user and debugger's screen; that code might give you trouble on Windows or with some buggy SVGA cards, though. For more info, look at section 12.3 of the DJGPP FAQ. > I then tried using rhide and I compiled it in the IDE and as soon > as I try to run or step or anything, I get a math error and the > program stops. Make sure you have the latest version of RHIDE. > Does anyone know a way I can get gdb to swap back into text mode to > give me listings when the program being debugged is in graphics > mode? (since I'm using xmode I'm not real hopeful here). One way to do this is to include in your program a function that toggles between text and graphics mode, and then call that function from GDB, when the program stops at a breakpoint. (GDB has a `call' command which can call arbitrary function in the debugged program.) For this to work, that function should redraw the screen once it switches to graphics. > Does anyone know how I can use these tools to follow the program in > assembly before it gets to main to try to get some clue about > what's happening? Put a breakpoint in a function called `__crt1_startup' or in `start', and use the `stepi' and `nexti' commands to step through the startup code on the assembly level. But why would you need to step through the startup code?