This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFA] Avoid infinite height for mingw GDB


> 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?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]