This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
This bug and patch might have already been submitted. There was considerable discussion of it on the mingw mailing list and I gave the patch to a couple of the participants. Christopher Faylor is aware of this bug and has a copy of the fixed source code file. Description of the bug: When an IDE launches GDB to debug a console application on Windows 95/98/ME platforms with the set new-console option, and the IDE communicates with GDB's stdin/stdout through pipes, the target application's console does not work. It displays the console window, but output to the console goes no where and input from the console (getchar(), e.g.) just locks up the program. This problem does not seem to exist on Windows NT/XP/2000 platforms. The problem is due to inconsistent implementation of CreateProcess with the win32 debugger api between platforms. Somehow the Win9x platform forces the target to inherit gdb's stdin/stdout handles, which are the pipes. It must have something to do with pipes not having three ends, I'm not sure. It's not really GDB's problem, but GDB has to find a way around it. The solution is for GDB to temporarily set its handles to INVALID_HANDLE_VALUE before launching the target and then restore the handles after the target is running. This must be done only when the new-console option is set. Otherwise a command-line run of GDB without set new-console would not work. To observe this bug, you must use an IDE that uses pipes to communicate with GDB. There are two such IDEs that I know of. One is VIDE, which exhibits this problem. (http://www.objectcentral.com/vide.htm). Make sure that you use the existing released gdb. I gave VIDE's author a patched one, and he might already be distributing it. The other IDE is Quincy 2002. (http://www.alstevens.com/quincy.html) It distributes a patched GDB which you can replace with the released version. Just put your gdb.exe in the gdb subdirectory. This must be a gdb built without the Insight hooks because Quincy does not use the -nw option. Build a hello-world application with MinGW from the IDE with debugging info, and step through it. Don't just run the application; that procedure does not use GDB. Step through the program and observe that the target's message to stdout does not display in the console window. Then restore the patched GDB that comes along with Quincy 2002, run the test again, and observe that the problem goes away. If it would help, I can walk a tester through the steps needed to install Quincy 2002 and get MinGW and gdb setup for the test. We can do it via email. Your submission instructions ask for a ChangeLog entry. I searched the website for a format but did not find one. If you'll point me in the right direction, I'll build one and send it to you. It would be helpful if the instructions on the CONTRIBUTE page included a link. Attached is the fixed win32-nat.c. I know that's not the way you prefer to get contributions, and I apologize, but I'm not all that familiar with how to work with CVS. A search of the file on the string QUINCY will turn up the very small patch it takes to fix this problem. It's in three places fairly near one another in the same function. I am virtually certain that the patch has no effect whatsoever in environments other than IDEs that launch GDB with pipes. I am equally certain that without this patch, GDB cannot be used in that environment on the 9x derived platforms. Thanks for looking at this. Al Stevens Dr, Dobb's Journal
Attachment:
win32-nat.c
Description: Binary data
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |