This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFA] Avoid infinite height for mingw GDB
- From: Eli Zaretskii <eliz at gnu dot org>
- To: Joel Brobecker <brobecker at adacore dot com>
- Cc: pierre dot muller at ics-cnrs dot unistra dot fr, gdb-patches at sourceware dot org
- Date: Wed, 17 Oct 2012 18:46:40 +0200
- Subject: Re: [RFA] Avoid infinite height for mingw GDB
- References: <000c01cdabf3$6a72bf40$3f583dc0$%muller@ics-cnrs.unistra.fr> <20121017162603.GL3050@adacore.com>
- Reply-to: Eli Zaretskii <eliz at gnu dot org>
> Date: Wed, 17 Oct 2012 09:26:03 -0700
> From: Joel Brobecker <brobecker@adacore.com>
> Cc: gdb-patches@sourceware.org
>
> > The mingw32 GDB debugger starts always with height set to infinite.
>
> I just wanted to confirm: This is when starging GDB in a Windows CMD
> window, right? There are other modes for GDB, for instance when started
> inside a cygwin "terminal", or through cygwin ssh. In that case, cygwin
> sets stdin/stdout as pipes, rather than pseudo ttys...
>
> > 2012-10-17 Pierre Muller <muller@ics.u-strasbg.fr>
> >
> > * windows-termcap.c (tgetent): Handle "li" and "co"
> > parameter.
>
> Thinko: tgetent -> tgetnum :).
>
> Some thoughts about the idea behind the patch:
>
> The problem with using rl_get_screen_size is that it does not really
> allow us to return a failure condition if unable to determine the
> screen size: rl_get_screen_size tries in that order:
> - the Windows API
> - the "COLUMNS"/"LINES" environment variable
> - tgetnum (hence the need for your guard)
> And if all of them fail, then it defaults to 80x24.
>
> A priori, I don't see anything that would break because of this.
> But I am not sure if this is the best thing to be doing. The Windows
> API seems to be straightforward, and I am wondering whether it might
> be just safer to use that in our tgetnum emulation. I know it's code
> duplication, and perhaps we could reuse the code in readline if
> _win_get_screensize was made non-static. But it really looks like
> re-use wouldn't bring us much in this case. If you simplify it a bit,
> it's a case of:
>
> hConOut = GetStdHandle (STD_OUTPUT_HANDLE);
> GetConsoleScreenBufferInfo (hConOut, &scr)
How about if we abandon the windows-termcap.c kludge entirely, and
instead use a MinGW build of ncurses? It builds out of the box, and
you can find a precompiled binary here:
http://sourceforge.net/projects/ezwinports/files/ncurses-5.9-w32-bin.zip/download
It already does the above, I'm sure, and its tgetnum doesn't fail on
Windows.
I've successfully used that to build Gawk (for its built-in debugger,
which uses Readline) and Hunspell, using MinGW. I don't see why it
won't do for GDB, although I didn't try.
As a nice bonus, we will be able to get rid of the MinGW #ifdef's in
Readline.
Any objections?