From: Luke D. <cod...@ho...> - 2002-09-09 03:59:06
|
Ah... do you mean you need a way to distinguish between the Mingw GCC 3.2 package by itself and the Mingw 2.0.0 full package at runtime? Since they are supposed to be equivalent I don't know how you could, but why would you want to? The GCC included with Mingw 2.0 is exactly the same as the separate GCC package, and it would be silly to rebuild GCC just to change the version number string to mention that it is part of the Mingw 2.0 bundle. Why isn't it enough for your IDE to know that you have GCC 3.2 installed? Luke Dunstan >From: "Al Stevens" <al...@al...> >To: <min...@li...> >Subject: Re: [Mingw-users] version numbers galore >Date: Sun, 8 Sep 2002 23:42:30 -0400 > > > > I am running into some version number confusion. My IDE is able to >report > > > which version of gcc it uses by finding the subdirectory > > > C:\mingw\\lib\gcc-lib\mingw32\3.2, for example. However, the MinGW >port >has > > > a different version number, 2.0.0-2, for example, which I cannot find > > > reported anywhere at runtime. > > > > You're confusing the MinGW all-in-one package version with the GCC > > package version. > >No, I'm not. I know the difference. I'm just grousing that the 2.0.0-2 >number is not among the helpful bits of info reported by gcc -v and I don't >know any reason why it could not be other than that probably no one else >saw >a need for it before now. > > > > > > The only clue to that number is the name of > > > the self-extracting executable, MinGW-2.0.0-2.exe, which users of an >IDE > > > should not be expected to keep, or, in some instances, ever have in >the > > > first place. Running gcc -v reports yet another version identification > > > related, it seems, to the date of the build and a build number for >that > > > date, as in "gcc version 3.2 (mingw special 20020817-1), which is >unrelated > > > to the version number as far as I can tell. I'm not sure why a >distribution > > > needs two version numbers. > > > > > > > Unrelated to what "version number", GCC's or the MinGW all-in-one > > package. > >Either one. But I was speaking specifically of the mingw package version. > > > See the <prefix>/doc/mingw/MinGW_PACKAGES.rtf file, perhaps that will > > clear up some of the mud. Please, let me know if anything else needs > > added. > >It would be a lot more useful if it was something other than .rtf. Plain >text would be better. Rtf is a PITA for an application to parse just to get >a few version numbers at runtime. But, since not all past MinGW >distributions have that doc subdirectory or the rtf file, I can't rely on >it >to get the info at runtime, anyway. (My IDE aims to work with all versions >back to and including mingw's port of 2.95.2) I know that I could manually >extract the info myself, but the IDE permits users to plug in whichever >compiler version they prefer, and extracting version data needs to be done >at runtime based on whatever comes in the package without intervention. > >Al Stevens >Dr. Dobb's Journal _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com |
From: Luke D. <cod...@ho...> - 2002-09-09 05:37:04
|
>From: "Al Stevens" <al...@al...> >To: "Luke Dunstan" <cod...@ho...>, ><min...@li...> >Subject: Re: [Mingw-users] version numbers galore >Date: Mon, 9 Sep 2002 01:14:57 -0400 > > > Ah... do you mean you need a way to distinguish between the Mingw GCC >3.2 > > package by itself and the Mingw 2.0.0 full package at runtime? > >Nope. > > > Since they > > are supposed to be equivalent I don't know how you could, but why would >you > > want to? The GCC included with Mingw 2.0 is exactly the same as the >separate > > GCC package, and it would be silly to rebuild GCC just to change the >version > > number string to mention that it is part of the Mingw 2.0 bundle. > >Then why rebuild it just to add the "mingw special 2002mmdd-n info?" Or >does >gcc get that data from an external file? If so, why not put all the >identifying data in it and not just some of it? The GCC 3.2 binary package was released before Mingw 2.0, and for each of the -1, -2, -3 updates the compiler itself has not changed, so it makes no sense to rebuild it. AFAIK the displayed timestamp has not changed either. I usually think of the Mingw 2.0 package as just an archive containing the gcc, binutils, etc. packages, not as a single unit of software. > > > Why isn't it enough for your IDE to know that you have GCC 3.2 >installed? > >Well, as we've seen in the last few days, sometimes a package is released >without everything it needs. That's why we're up to 2.0.0-3 in just a few >days, all of which are GCC 3.2. To assess a student's problem, I need to >know specifically which package the student installed. > >Al Stevens >Dr. Dobb's Journal It seems that you need some sort of additional program or text file to find out the full package version, because GCC is not the appropriate place to put it. I wonder if the RTF file Earnie mentioned could be automatically provided in text format too (if RTF is necessary)? You would still need to check the versions of gcc, binutils, etc. individually because a user could update one of these packages after installing the 2.0 full release. Luke Dunstan _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com |
From: Al S. <al...@al...> - 2002-09-09 14:24:58
|
> The GCC 3.2 binary package was released before Mingw 2.0, and for each of > the -1, -2, -3 updates the compiler itself has not changed, so it makes no > sense to rebuild it. AFAIK the displayed timestamp has not changed either. Hmm. That tends to emphasize the need for something available at runtime that identifies the distribution being used. The information being displayed is ambiguous assuming that -1, -2, and -3 all display the same timestamp and assuming that there is anything whatsoever different in the updates, which, of course, there would be. ================== gcc -v [snip] gcc version 3.2 (mingw special 20020817-1) ================== Given that three different updates display the same release/version/update/whatever timestamp text, and that no other display or recorded data augment it, this display is indeed ambiguous. As any self-righteous configuration manager will tell you. :-) Inasmuch as the "mingw sepcial" text displayed by gcc -v is not in the specs file, I assume that the gcc program itself gets changed to display it, unless there's another file somewhere that contains port-specific version data. Incidentally, 3.1 doesn't display any such string whereas 2.95.2 and 2.95.3-6 do, so something gets changed somewhere. Wherever the text comes from, it could include the 2.0.0-3 information. But if I'm the only one who needs or wants it, I won't ask the volunteers to burn any valuable time adding it. I'll just get by with whatever is available. But, to continue flailing this deceased equine, I'd think the project would need it for its own purposes. If someone downloads, installs, and then deletes the self-extracting exe to make space, and then asks a question, what question do you ask them to know which release/update/whatever they are using? (The obvious answer to that question is, "Our users are programmers and smart people; they can figure it out," or, "The question or problem will reveal the version." My users are students, some of whom ask questions you wouldn't believe.) Al Stevens Dr. Dobb's Journal |
From: Earnie B. <ear...@ya...> - 2002-09-09 18:02:39
|
I may be able to supply something in the MinGW.INI file found in the <WINDOWS> directory. I'll get back to you on that. Yes, it doesn't help currently but maybe in the future. Earnie. Al Stevens wrote: > > > The GCC 3.2 binary package was released before Mingw 2.0, and for each of > > the -1, -2, -3 updates the compiler itself has not changed, so it makes no > > sense to rebuild it. AFAIK the displayed timestamp has not changed either. > > Hmm. That tends to emphasize the need for something available at runtime > that identifies the distribution being used. The information being displayed > is ambiguous assuming that -1, -2, and -3 all display the same timestamp and > assuming that there is anything whatsoever different in the updates, which, > of course, there would be. > ================== > gcc -v > [snip] > gcc version 3.2 (mingw special 20020817-1) > ================== > Given that three different updates display the same > release/version/update/whatever timestamp text, and that no other display or > recorded data augment it, this display is indeed ambiguous. As any > self-righteous configuration manager will tell you. :-) > > Inasmuch as the "mingw sepcial" text displayed by gcc -v is not in the specs > file, I assume that the gcc program itself gets changed to display it, > unless there's another file somewhere that contains port-specific version > data. Incidentally, 3.1 doesn't display any such string whereas 2.95.2 and > 2.95.3-6 do, so something gets changed somewhere. Wherever the text comes > from, it could include the 2.0.0-3 information. But if I'm the only one who > needs or wants it, I won't ask the volunteers to burn any valuable time > adding it. I'll just get by with whatever is available. > > But, to continue flailing this deceased equine, I'd think the project would > need it for its own purposes. If someone downloads, installs, and then > deletes the self-extracting exe to make space, and then asks a question, > what question do you ask them to know which release/update/whatever they are > using? > > (The obvious answer to that question is, "Our users are programmers and > smart people; they can figure it out," or, "The question or problem will > reveal the version." My users are students, some of whom ask questions you > wouldn't believe.) > > Al Stevens > Dr. Dobb's Journal > > ------------------------------------------------------- > This sf.net email is sponsored by: OSDN - Tired of that same old > cell phone? Get a new here for FREE! > https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390 > _______________________________________________ > MinGW-users mailing list > Min...@li... > > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users |
From: Randy W. S. <RandyS@ThePierianSpring.org> - 2002-09-11 00:32:13
|
> -----Original Message----- > From: min...@li... > [mailto:min...@li...]On Behalf Of Earnie Boyd > Sent: Monday, September 09, 2002 2:03 PM > To: Al Stevens > Cc: min...@li... > Subject: Re: [Mingw-users] version numbers galore > > > I may be able to supply something in the MinGW.INI file found in the > <WINDOWS> directory. I'll get back to you on that. Yes, it doesn't > help currently but maybe in the future. > > Earnie. > > Al Stevens wrote: > > > > > The GCC 3.2 binary package was released before Mingw 2.0, and > for each of > > > the -1, -2, -3 updates the compiler itself has not changed, > so it makes no > > > sense to rebuild it. AFAIK the displayed timestamp has not > changed either. > > > > Hmm. That tends to emphasize the need for something available at runtime > > that identifies the distribution being used. The information > being displayed > > is ambiguous assuming that -1, -2, and -3 all display the same > timestamp and > > assuming that there is anything whatsoever different in the > updates, which, > > of course, there would be. > > ================== > > gcc -v > > [snip] > > gcc version 3.2 (mingw special 20020817-1) > > ================== > > Given that three different updates display the same > > release/version/update/whatever timestamp text, and that no > other display or > > recorded data augment it, this display is indeed ambiguous. As any > > self-righteous configuration manager will tell you. :-) > > > > Inasmuch as the "mingw sepcial" text displayed by gcc -v is not > in the specs > > file, I assume that the gcc program itself gets changed to display it, > > unless there's another file somewhere that contains > port-specific version > > data. Incidentally, 3.1 doesn't display any such string whereas > 2.95.2 and > > 2.95.3-6 do, so something gets changed somewhere. Wherever the > text comes > > from, it could include the 2.0.0-3 information. But if I'm the > only one who > > needs or wants it, I won't ask the volunteers to burn any valuable time > > adding it. I'll just get by with whatever is available. > > > > But, to continue flailing this deceased equine, I'd think the > project would > > need it for its own purposes. If someone downloads, installs, and then > > deletes the self-extracting exe to make space, and then asks a question, > > what question do you ask them to know which > release/update/whatever they are > > using? > > > > (The obvious answer to that question is, "Our users are programmers and > > smart people; they can figure it out," or, "The question or problem will > > reveal the version." My users are students, some of whom ask > questions you > > wouldn't believe.) > > > > Al Stevens > > Dr. Dobb's Journal > > Wouldn't the versions of the individual packages be better? Either way if gcc is the compiler you should be able to have your ide compile the code below and get the versions of the packages. Then, if you need to know the version of the MinGW distribution, you can match these versions against a table consisting of the versions of packages included in each of the MinGW distributions. HTH, Randy. #include <stdio.h> #include "w32api.h" #include "_mingw.h" int main( int argc, char **argv ) { printf( "MinGW w32api version %d.%d\n", __W32API_MAJOR_VERSION, __W32API_MINOR_VERSION ); printf( "MinGW Runtime version %d.%d\n", __MINGW32_MAJOR_VERSION, __MINGW32_MINOR_VERSION ); printf( "GCC version %d.%d\n", __GNUC__, __GNUC_MINOR__ ); return 0; } |
From: <dan...@ya...> - 2002-09-11 01:02:22
|
--- "Randy W. Sims" <RandyS@ThePierianSpring.org> wrote: > > -----Original > > Wouldn't the versions of the individual packages be better? Either way > if gcc is the compiler you should be able to have your ide compile the > code below and get the versions of the packages. Then, if you need to > know the version of the MinGW distribution, you can match these > versions against a table consisting of the versions of packages > included in each of the MinGW distributions. > > HTH, > Randy. > > #include <stdio.h> > #include "w32api.h" > #include "_mingw.h" > > int > main( int argc, char **argv ) > { > printf( "MinGW w32api version %d.%d\n", > __W32API_MAJOR_VERSION, > __W32API_MINOR_VERSION > ); > > printf( "MinGW Runtime version %d.%d\n", > __MINGW32_MAJOR_VERSION, > __MINGW32_MINOR_VERSION > ); > > printf( "GCC version %d.%d\n", > __GNUC__, > __GNUC_MINOR__ > ); > > return 0; > } And you could get binutils version from bfd.h #include <bfd.h> ... printf( "Binutils version %s\n", BFD_VERSION_STRING ); GCC 3.x also defines __VERSION__ as string; printf("GCC version: %s\n", __VERSION__); outputs: GCC version: 3.3 20020910 (experimental) Danny > > > > > ------------------------------------------------------- > In remembrance > www.osdn.com/911/ > _______________________________________________ > MinGW-users mailing list > Min...@li... > > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users http://mobile.yahoo.com.au - Yahoo! Messenger for SMS - Now send & receive IMs on your mobile via SMS |
From: Al S. <al...@al...> - 2002-09-11 18:18:10
|
Thanks to Earnie, Randy and Danny for the version number suggestions, which will provide what I need. This really is a helpful mail list. Now I have another simple question. First some not-so-simple background: The Quincy IDE (an experimental version, not yet available for download) launches the MinGW port of the gdb program for debugging. Quincy uses pipes in place of stdin/stdout/stderr to emulate a command line user. The interface works well, but there is a problem. When Quincy launches gdb, which launches a console application to debug, and the host computer runs Windows 98 or ME, the application's stdout does not display on the application's console window. Everything works properly on Windows XP, however, and, I presume, 2000 and NT. I decided to see how Bruce Wampler does it in VIDE, but a test reveals that his debugger interface exhibits the same problem. This is something that Manu is likely to encounter, too, when he adds a debugger to Visual MinGW. (Manu, if you've already run into this and solved it, HELP!) It has been mentioned here that the MinGW gdb is an old version. Maybe a newer version would not have this problem. I downloaded the cygwin debugger, which some folks here have mentioned, only to find that it is not a command line debugger at all, but a GUI application. Bummer. Before I immerse myself in the daunting task of porting gdb from source to something that works in the IDE environment, I will ask here: <simple question> Is there somewhere I can download a newer command line gdb that is built to work with either cygwin1.dll or as a MinGW executable? </simple question> My google search has not turned one up. I fear that the problem is the platform api and not gdb itself. Quincy is, regrettably, an MFC application, so I do not refer to the MinGW winapi but rather the underlying operating system api. The likely solution is to embed the debugger code into the IDE application, but, before I do that, I want to try other alternatives, and that means trying as many different command line gdbs as I can find. (If someone is working on porting the latest gdb to MinGW, I'm a willing beta tester.) I have a number of older gdbs that I will be trying today, but I'd prefer to have something that knows more about the debug info (stabs) that support contemporary C++. I don't mean to turn this into a "why would anyone want to do that?" or "why don't you do this instead?" thread. I welcome all such suggestions, but you might prefer to send them to me privately so as to not clog the list with gdb esoterica, for which I would feel guilty. Al Stevens Dr. Dobb's Journal |
From: Greg C. <chi...@mi...> - 2002-09-11 19:10:51
|
Al Stevens wrote: > > It has been mentioned here that the MinGW gdb is an old version. Maybe a > newer version would not have this problem. I downloaded the cygwin debugger, > which some folks here have mentioned, only to find that it is not a command > line debugger at all, but a GUI application. Bummer. Try this option to run it as a command-line debugger: --nw Do not use a window interface. That way, it looks like it runs as a console app, at least with this version: C:/tmp[0]$/cygwin/bin/gdb.exe --version GNU gdb 5.0 (20010428-1) Copyright 2001 Free Software Foundation, Inc. which is the latest I've downloaded from cygwin, but probably not the latest one they've released. |
From: Oscar F. <of...@wa...> - 2002-09-11 20:17:43
|
"Al Stevens" <al...@al...> writes: [snip] > It has been mentioned here that the MinGW gdb is an old version. Maybe a > newer version would not have this problem. I downloaded the cygwin debugger, > which some folks here have mentioned, only to find that it is not a command > line debugger at all, but a GUI application. Bummer. That's Insight. It is a GUI with gdb embedded. As Greg suggested, the -nw switch cures this. But keep reading. > Before I immerse myself in the daunting task of porting gdb from source to > something that works in the IDE environment, I will ask here: > > <simple question> > Is there somewhere I can download a newer command line gdb that is built to > work with either cygwin1.dll or as a MinGW executable? > </simple question> Well, I'm using the 5.2.1 version built from sources under Cygwin. This is the real 'gdb', not Insight, so no -nw switch needed. > My google search has not turned one up. > > I fear that the problem is the platform api and not gdb itself. As for the console problem is related, I think so. Maybe an investigation about the different Win32 APIs for launching applications could yield some interesting stuff. [snip] > I have a number of older gdbs that I will be trying today, but I'd prefer to > have something that knows more about the debug info (stabs) that support > contemporary C++. As others said on this list just a few days ago and my experience confirms, gdb 5.1.1 doesn't work well with C++. You really want to use the latest one. [snip] -- Oscar |
From: Al S. <al...@al...> - 2002-09-11 20:42:17
|
> > It has been mentioned here that the MinGW gdb is an old version. Maybe a > > newer version would not have this problem. I downloaded the cygwin debugger, > > which some folks here have mentioned, only to find that it is not a command > > line debugger at all, but a GUI application. Bummer. > > That's Insight. It is a GUI with gdb embedded. As Greg suggested, the > -nw switch cures this. But keep reading. I haven't downloaded Insight. I downloaded gdb binaries from cygwin.com. It's gdb.exe, some dlls, and some other stuff related to the tcl libraries. Gdb.exe from cygwin.com is a gui app that needs -nw to run from the command line. I haven't tried Insight yet although I might do that next. > Well, I'm using the 5.2.1 version built from sources under > Cygwin. This is the real 'gdb', not Insight, so no -nw switch needed. Would you be willing to send me the binary that you built? It would save me figuring out how to do that. Thanks. Al Stevens Dr. Dobb's Journal |
From: Oscar F. <of...@wa...> - 2002-09-11 21:06:14
|
"Al Stevens" <al...@al...> writes: > > > It has been mentioned here that the MinGW gdb is an old version. Maybe a > > > newer version would not have this problem. I downloaded the cygwin > debugger, > > > which some folks here have mentioned, only to find that it is not a > command > > > line debugger at all, but a GUI application. Bummer. > > > > That's Insight. It is a GUI with gdb embedded. As Greg suggested, the > > -nw switch cures this. But keep reading. > > I haven't downloaded Insight. Yes, you did :-) > I downloaded gdb binaries from cygwin.com. > It's gdb.exe, some dlls, and some other stuff related to the tcl libraries. ^^^^ ^^^^^^^^^^^^^ The Insight is the "official" GUI for gdb. They distribute the thing with a special gdb.exe that loads Insight on startup. Or maybe gdb.exe comes with code for checking for the presence of those dll's and run as a GUI if found. http://sources.redhat.com/insight/ The "real" gdb is a monolithic executable. > Gdb.exe from cygwin.com is a gui app that needs -nw to run from the > command line. I haven't tried Insight yet although I might do that > next. > > > Well, I'm using the 5.2.1 version built from sources under > > Cygwin. This is the real 'gdb', not Insight, so no -nw switch needed. > > Would you be willing to send me the binary that you built? Of course. > It would save me figuring out how to do that. Thanks. It's really simple: ./configure make make install But anyways it's on the way. -- Oscar |
From: Al S. <al...@al...> - 2002-09-12 00:03:39
|
> > I haven't downloaded Insight. > > Yes, you did :-) > > > I downloaded gdb binaries from cygwin.com. > > It's gdb.exe, some dlls, and some other stuff related to the tcl libraries. > ^^^^ ^^^^^^^^^^^^^ > > The Insight is the "official" GUI for gdb. They distribute the thing > with a special gdb.exe that loads Insight on startup. Or maybe gdb.exe > comes with code for checking for the presence of those dll's and run > as a GUI if found. > That must be what fooled me. They have separate downloads for gdb and for insight making them look like separate programs. The gdb download did not download anything named insight. > > Would you be willing to send me the binary that you built? > > Of course. Thank you. |
From: Christopher F. <cg...@re...> - 2002-09-12 02:24:40
|
On Wed, Sep 11, 2002 at 08:03:25PM -0400, Al Stevens wrote: > >> > I haven't downloaded Insight. >> >> Yes, you did :-) >> >> > I downloaded gdb binaries from cygwin.com. >> > It's gdb.exe, some dlls, and some other stuff related to the tcl >libraries. >> ^^^^ >^^^^^^^^^^^^^ >> >> The Insight is the "official" GUI for gdb. They distribute the thing >> with a special gdb.exe that loads Insight on startup. Or maybe gdb.exe >> comes with code for checking for the presence of those dll's and run >> as a GUI if found. >> > >That must be what fooled me. They have separate downloads for gdb and for >insight making them look like separate programs. The gdb download did not >download anything named insight. cygwin has only one download called gdb. It brings up the gui ("insight") by default. The gdb sources can be downloaded either as raw console-mode gdb or as insight. If you download insight then the gdb that you build will start insight. We're actually working on making this into two separate "insight" and "gdb" commands. I hope that gdb 5.4 will actually have both of these broken out. cgf |
From: Christopher F. <cg...@re...> - 2002-09-12 02:21:42
|
On Wed, Sep 11, 2002 at 10:17:29PM +0200, Oscar Fuentes wrote: >>I have a number of older gdbs that I will be trying today, but I'd >>prefer to have something that knows more about the debug info (stabs) >>that support contemporary C++. > >As others said on this list just a few days ago and my experience >confirms, gdb 5.1.1 doesn't work well with C++. You really want to use >the latest one. And there are problems even with that. C++ is an ongoing problem for gdb. Another thing to consider is building gdb with the "mi" interface, configure --enable-gdbmi . That is specifically designed to allow the control of gdb via external things like an IDE. It isn't 100% complete yet but it is being actively worked on. cgf |
From: Earnie B. <ear...@ya...> - 2002-09-12 02:06:44
|
Al Stevens wrote: > > Thanks to Earnie, Randy and Danny for the version number suggestions, which > will provide what I need. This really is a helpful mail list. > > Now I have another simple question. First some not-so-simple background: The > Quincy IDE (an experimental version, not yet available for download) > launches the MinGW port of the gdb program for debugging. Quincy uses pipes > in place of stdin/stdout/stderr to emulate a command line user. The > interface works well, but there is a problem. When Quincy launches gdb, > which launches a console application to debug, and the host computer runs > Windows 98 or ME, the application's stdout does not display on the > application's console window. Everything works properly on Windows XP, > however, and, I presume, 2000 and NT. > I think this is due to brokeness in Win32. Do you use _pipe and spawn or _popen? You may also need to check the *ConsoleScreenBuffer* win32 APIs. Earnie. |
From: Al S. <al...@al...> - 2002-09-12 02:34:40
|
> > I think this is due to brokeness in Win32. Do you use _pipe and spawn > or _popen? You may also need to check the *ConsoleScreenBuffer* win32 > APIs. I use CreatePipe and CreateProcess. An MSDN search turns up nothing about ConsoleScreenBuffer. in the Win32 API. Is there a prefix on the function names? I think the problem is related to the fact that my IDE program is two levels away from the program having the problem. The IDE launches gdb using pipes as stdin/stdout, and gdb launches the program to debug, which is the program that loses where stdin/stdout are supposed to be. It has to be a bug in the Win9x win32 implementation. Every version of gdb that I've put in there so far does the same thing. I think if I can look into gdb and see how it launches the program being debugged, I might be able to change it. That's next. Al Stevens Dr. Dobb's Journal |
From: Christopher F. <cg...@re...> - 2002-09-12 02:44:15
|
On Wed, Sep 11, 2002 at 10:34:18PM -0400, Al Stevens wrote: >I think if I can look into gdb and see how it launches the program being >debugged, I might be able to change it. That's next. It launches the program via CreateProcess using the DEBUG_PROCESS flag. Have you tried saying something like (untested): gdb --tty=con foo.exe That *might* cause gdb to use the "con" device for the debugged process. cgf |
From: Al S. <al...@al...> - 2002-09-12 15:35:03
|
----- Original Message ----- From: "Christopher Faylor" <cg...@re...> To: "Al Stevens" <al...@al...> Cc: <min...@li...> Sent: Wednesday, September 11, 2002 10:44 PM Subject: Re: [Mingw-users] was: version numbers galore. Now a gdb question > On Wed, Sep 11, 2002 at 10:34:18PM -0400, Al Stevens wrote: > >I think if I can look into gdb and see how it launches the program being > >debugged, I might be able to change it. That's next. > > It launches the program via CreateProcess using the DEBUG_PROCESS flag. Yes, it has to in order to use the Win32 debugger api. My old IDE had its own debugger that did that. I abandoned it when the stabs that the compiler emits for C++ got too thorny to parse. I need to look into what flags gdb uses with respect to the target's console handles. > Have you tried saying something like (untested): > > gdb --tty=con foo.exe > > That *might* cause gdb to use the "con" device for the debugged process. I've been playing with that but no luck so far. |
From: Earnie B. <ear...@ya...> - 2002-09-12 02:57:34
|
Al Stevens wrote: > > > > > I think this is due to brokeness in Win32. Do you use _pipe and spawn > > or _popen? You may also need to check the *ConsoleScreenBuffer* win32 > > APIs. > > I use CreatePipe and CreateProcess. An MSDN search turns up nothing about > ConsoleScreenBuffer. in the Win32 API. Is there a prefix on the function > names? > CreateConsoleScreenBuffer, SetConsoleScreenBufferSize, SetConsoleActiveScreenBuffer, GetConsoleScreenBufferInfo. > I think the problem is related to the fact that my IDE program is two levels > away from the program having the problem. The IDE launches gdb using pipes > as stdin/stdout, and gdb launches the program to debug, which is the program > that loses where stdin/stdout are supposed to be. It has to be a bug in the > Win9x win32 implementation. Every version of gdb that I've put in there so > far does the same thing. > Does your IDE have a console associated with it? See AllocConsole. > I think if I can look into gdb and see how it launches the program being > debugged, I might be able to change it. That's next. > Or take a look at insight to see what they did. Earnie. |
From: Al S. <al...@al...> - 2002-09-12 15:10:58
|
[snip] > Or take a look at insight to see what they did. I might have to do that. Insight is a gui app with the gdb code statically linked in. The copy of gdb.exe that I downloaded has only one executable. The "IDE -> gdb -> target" situation that I have encountered is not a problem in Insight for that reason. I might have to embed gdb in my IDE the way Insight does, which I don't want to do, because I want users to be able to plug in whichever compiler they prefer. |
From: Christopher F. <cg...@re...> - 2002-09-12 16:58:39
|
On Thu, Sep 12, 2002 at 11:10:45AM -0400, Al Stevens wrote: >[snip] > >> Or take a look at insight to see what they did. > >I might have to do that. Insight is a gui app with the gdb code statically >linked in. The copy of gdb.exe that I downloaded has only one executable. >The "IDE -> gdb -> target" situation that I have encountered is not a >problem in Insight for that reason. I might have to embed gdb in my IDE the >way Insight does, which I don't want to do, because I want users to be able >to plug in whichever compiler they prefer. I really don't think this is feasible. gdb isn't really "embedded" in insight. Rather, there are hooks in gdb for insight. It's sort of the opposite of what I think you are implying. Embedding another debugger in a way similar to insight is going in the opposite direction from current gdb development. We're actually very slowly trying to separate insight from gdb by using the MI. I guess I should introduce myself, in case it isn't clear. I'm the maintainer for the Win32 ports for gdb. I've hacked at the code in win32-nat.c which we are talking about here. I'll reiterate that using the MI interface to gdb is the "approved" way of controlling a slave gdb. It may be adequate for what you want to do. I don't know. You might get more specific help by sending email to the gdb at sources dot redhat dot com mailing list, though. cgf |
From: Al S. <al...@al...> - 2002-09-12 18:14:27
|
> >[snip] > > I might have to embed gdb in my IDE the > >way Insight does, which I don't want to do, because I want users to be able > >to plug in whichever compiler they prefer. > > I really don't think this is feasible. gdb isn't really "embedded" in insight. > Rather, there are hooks in gdb for insight. Okay, understood. I don't think it would be that difficult except that my IDE is compiled with VC++. You can make almost any console app an embedded app by changing its main function name to something like gdbmain and linking everything with the host, assuming the console app always exits by returning from main. The host simply calls gdbmain. Name collisions should not be a problem if the host application uses C++ namespaces. The problem would be porting all that gcc code to VC++. Big job. > I guess I should introduce myself, in case it isn't clear. I'm the maintainer > for the Win32 ports for gdb. I've hacked at the code in win32-nat.c which > we are talking about here. Hi. Perhaps you can answer this unrelated question. What is it in the new gdb that takes so long after: break main run to return to the prompt? Even in a simple helloworld.c program. The venerable old 5.1.1 comes back right away. On a 1.5 Ghz PC it sometimes takes several seconds before the prompt displays. There's no disk thrashing that I can see. What the heck is it doing all that time? > I'll reiterate that using the MI interface to gdb is the "approved" way of > controlling a slave gdb. It may be adequate for what you want to do. I > don't know. 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. Al Stevens Dr. Dobb's Journal |
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 |
From: Al S. <al...@al...> - 2002-09-13 13:51:10
|
----- Original Message ----- From: "Marc Kealy" <ma...@ke...> > From the above text, I'm not sure that piping a third level process (via > gdb) is still your main concern. It is. If I could solve that problem, the MI discussion would be moot. Using MI might be a way to get around the problem because gdb would launch the target program without its own console and the IDE would substitute itself for the target program's stdin/stdout. The problem is separating gdb console output from target output. > Assuming it is, may I suggest:- [code snipped] > If this works for you, then at least you know for sure that it is a gdb > problem. No, I'm afraid would not know that. If fact, having carefully read the gdb code, I am sure that it is *not* a gdb problem. I am sure that the problem is because of inconsistences in how the win32 debugger apis work between win32 platforms. > 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. Your program works because your interim process, in this case your stub for gdb, does not use the debugger API to launch the tertiary process by including the flag DEBUG_PROCESS or DEBUG_ONLY_THIS_PROCESS. (There's a lot more to it that that, but you get the idea.) Furthermore, your program sequence seems to be passing the inherited handles all the way to the target (tertiary) process, which is not what is wanted here. Consequently, your stub does not really simulate what gdb does. But thanks for the suggestion, nonetheless. [To the moderators: If you think these discussions are straying off-topic, please jump in and say so. They are quite relevant to my use of MinGW, and would be of interest to anyone who writes a front-end for any win32 port of gdb, but I don't want to abuse the bandwidth. By exposing this problem to your membership, I have learned many things about what I am trying to do, so I appreciate your indulgence.] Al Stevens Dr. Dobb's Journal |
From: Earnie B. <ear...@ya...> - 2002-09-13 14:05:33
|
Al Stevens wrote: > > [To the moderators: If you think these discussions are straying off-topic, > please jump in and say so. They are quite relevant to my use of MinGW, and > would be of interest to anyone who writes a front-end for any win32 port of > gdb, but I don't want to abuse the bandwidth. By exposing this problem to > your membership, I have learned many things about what I am trying to do, so > I appreciate your indulgence.] > We have long determined that this type of topic/post is on target for this list. And, trust me, I have no problem stating a post OT. Earnie. |