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]

contribution to cygwin gdb


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]