From: Marc K. <ma...@ke...> - 2002-09-13 11:40:35
|
From: "Al Stevens" <al...@al...> > I've been looking at MI closely. So far I haven't had any problem parsing > the CLI dialog, although MI might be a safer way to protect myself from > changes in the messages and their sequence. The problem with using MI is > that it is not available in older versions of the GCC and the IDE supports > older compilers. I could be easily talked out of that concern, but the real > concern is that so far I have not seen a way with MI to reveal which text > was written to stdout by gdb and which text was written by the application > which might coincidentally resemble MI text. I'll keep playing with it, > though. Perhaps if it surrounded every one of its messages with things like > the two little arrow characters that annotate 1 and 2 use, it would be > easier. Target programs can be expected not to write those things to the > console. A front end needs to differentiate between text written by gdb and > text written by the target application. > > The new-console option would not be appropriate in this case because that's > the source of the error. I just changed the CreateProcess call in > win32-nat.c so that the "inherit handles" flag is false, and it did not > correct the problem. I'll keep plugging away at it. There are some other > mods I haven't tried yet. the win32-nat.c code is straightforward. From the above text, I'm not sure that piping a third level process (via gdb) is still your main concern. Assuming it is, may I suggest:- Create the pipe in your main launch code Set your output handles, ie:- SetStdHandle(STD_OUTPUT_HANDLE, hWritePipe); SetStdHandle(STD_ERROR_HANDLE, hWritePipe); Instead of launching gdb, launch the following program. ------------------------- #include <iostream> #include <windows.h> int main() { STARTUPINFO siStartInfo; ZeroMemory(&siStartInfo,sizeof(STARTUPINFO)); siStartInfo.cb=sizeof(STARTUPINFO); PROCESS_INFORMATION piProInfo; std::cout << "Starting level 3 process...\n\n" << std::flush; // Change path to suit if (!CreateProcess(0, "C:\\mingw\\bin\\gcc -v", 0, 0, false, 0, 0, 0, &siStartInfo, &piProInfo)) std::cout << "Could not create process!\n\n"; else { WaitForSingleObject(piProInfo.hProcess, INFINITE); CloseHandle(piProInfo.hProcess); CloseHandle(piProInfo.hThread); } return 0; } -------------------------- If this works for you, then at least you know for sure that it is a gdb problem. If this fails, then the problem is most likely in the way the pipe is implemented. As I've said before, this works fine for me. I know this seems obvious and you may have done this already, but I have no way of knowing. -- Marc |