MinGW gdb run in non-DOS terminal

MinGW gdb run in non-DOS terminal

[Joel Brobecker]

Hello,

Starting to experiment a bit with MinGW-hosted debuggers, I noticed that
when it is run outside of the DOS window, the terminal handling is a bit
strange. The most obvious issue is when the debugger prints an error:
the actual printing on screen of the error message is delayed and only
finally printed after the next GDB prompt.

This happens when in a DOS window running cygwin bash, when ssh'ing
from an xterm to the machine and then running GDB, or when running
GDB from GPS, which opens a pseudo-tty (I think!) to GDB. On the other
hand, it works great when run in a DOS window.

Has anybody else seen this? Maybe there is a missing-flush issue
somewhere... Or maybe there is a workaround I don't know about?
Otherwise, I'll have a look at this next.

Thanks,
-- 
Joel

Re: MinGW gdb run in non-DOS terminal

[Daniel Jacobowitz]

On Mon, May 01, 2006 at 10:05:12AM -0700, Joel Brobecker wrote:
> Hello,
> 
> Starting to experiment a bit with MinGW-hosted debuggers, I noticed that
> when it is run outside of the DOS window, the terminal handling is a bit
> strange. The most obvious issue is when the debugger prints an error:
> the actual printing on screen of the error message is delayed and only
> finally printed after the next GDB prompt.
> 
> This happens when in a DOS window running cygwin bash, when ssh'ing
> from an xterm to the machine and then running GDB, or when running
> GDB from GPS, which opens a pseudo-tty (I think!) to GDB. On the other
> hand, it works great when run in a DOS window.
> 
> Has anybody else seen this? Maybe there is a missing-flush issue
> somewhere... Or maybe there is a workaround I don't know about?
> Otherwise, I'll have a look at this next.

It is roughly unsolvable.  A cygwin "terminal" is in fact a Windows
pipe; isatty() returns false, therefore the C library selects
line-buffered mode, which is a pretty standard thing for C runtimes
to do.

I suppose that if the CLI is in use, you could automatically turn off
buffering.  But there may be plenty of other problems... I talked with
Chris about somehow using Windows consoles for this instead of pipes
(i.e. changing Cygwin), and I believe the outcome of that discussion
was that it might be possible, or might not, but would definitely not
be easy.

-- 
Daniel Jacobowitz
CodeSourcery

Re: MinGW gdb run in non-DOS terminal

[Joel Brobecker]

> It is roughly unsolvable.  A cygwin "terminal" is in fact a Windows
> pipe; isatty() returns false, therefore the C library selects
> line-buffered mode, which is a pretty standard thing for C runtimes
> to do.

:-(. In fact, I see the same in GPS where cygwin is nowhere in sight.

> I suppose that if the CLI is in use, you could automatically turn off
> buffering.  But there may be plenty of other problems...

Maybe we should start with that. Would you mind pointing me in the
area where this should be done? I can experiment with that and see
if we have any other obvious problems.

-- 
Joel

Re: MinGW gdb run in non-DOS terminal

[Daniel Jacobowitz]

On Mon, May 01, 2006 at 10:22:16AM -0700, Joel Brobecker wrote:
> > It is roughly unsolvable.  A cygwin "terminal" is in fact a Windows
> > pipe; isatty() returns false, therefore the C library selects
> > line-buffered mode, which is a pretty standard thing for C runtimes
> > to do.
> 
> :-(. In fact, I see the same in GPS where cygwin is nowhere in sight.

What's it connected to then?  A pipe or a console?

> > I suppose that if the CLI is in use, you could automatically turn off
> > buffering.  But there may be plenty of other problems...
> 
> Maybe we should start with that. Would you mind pointing me in the
> area where this should be done? I can experiment with that and see
> if we have any other obvious problems.

Just use setvbuf, I presume the Microsoft runtime has that.

-- 
Daniel Jacobowitz
CodeSourcery

Re: MinGW gdb run in non-DOS terminal

[Joel Brobecker]

> What's it connected to then?  A pipe or a console?

I am not very familiar with this part of GPS, but I had a look and
it seems to me that they are using pipes.

> Just use setvbuf, I presume the Microsoft runtime has that.

It does, and in fact, provides a significant improvement in the
ordering of the output, and our testsuite didn't detect any
complications from this. I just have a prototype right now, but
would this be interesting to others?

-- 
Joel