Re: [Mingw-users] was: version numbers galore. Now a gdb question

[Christopher F. <cg...@re...>]

On Thu, Sep 12, 2002 at 02:09:52PM -0400, Al Stevens wrote:
>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?

It's the, er, framis unalignment static replacement drive...

:-)  Sorry.  I don't know.  I've noticed some strange slowdowns myself
and I haven't had time to investigate them.  I don't notice the problem
as much on linux, though, which I guess is no surprise.

>> 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 remember the discussion of intermingling has come up before but I
don't remember what the outcome was.

You're mentioning gcc above.  Do you mean gdb?  gcc should not matter in
this scenario, but you do have to use a newer (the newer the better) gdb
to get the full benefit of MI.

cgf