building gdb with TUI support on Windows

building gdb with TUI support on Windows

[Ofir Cohen]

Hi guys,
I'm trying to build gdb from source with TUI support on Windows.
I'm using msys2 with MinGWx64.
It seems non-trivial, and is accompanied by undesired behavior.

I'm addressing this mailing list after a long period of trying by myself
and because I couldn't find a decent place where this could be solved.

I manage to build by commenting out tputs() implementation in
gdb/windows-termcap.c
(so the ncurses tputs is used instead).

However,
when I run: "gdb --tui"
from msys2 I get a "TUI mode not supported".

When I run it from DOS (with mingw64 paths in the PATH), it runs but I
cannot move the text

cursor to left arrow and right arrow), and even more annoying, I can't
use the CTRL+R

(history lookup).

I saw some post about gdb with TUI support on Windows:
http://migeel.sk/blog/2009/04/15/compiling-gdb-under-windows/

But it didn't help.

Do you have any idea how to get it done right?

P.S. this is how I build
export FLAGS="--enable-tui=no --with-expat --disable-gdbserver
--with-sysroot=\"remote:\" --build=x86_64-w64-mingw32"
./configure $FLAGS
make -j 8

Your help is very much appreciated =].

Thanks,
Ofir Cohen

Re: building gdb with TUI support on Windows

[Eli Zaretskii]

> Date: Fri, 26 Dec 2014 02:13:36 +0200
> From: Ofir Cohen <ofircohenn@gmail.com>
> 
> I'm trying to build gdb from source with TUI support on Windows.
> I'm using msys2 with MinGWx64.
> It seems non-trivial, and is accompanied by undesired behavior.
> 
> I'm addressing this mailing list after a long period of trying by myself
> and because I couldn't find a decent place where this could be solved.
> 
> I manage to build by commenting out tputs() implementation in
> gdb/windows-termcap.c
> (so the ncurses tputs is used instead).

Are you sure this is the only place where you need changes in order to
use ncurses?  There used to be quite a few places where GDB and
readline worked around the missing curses library on Windows, and
those places were never modified to account for ncurses being
available on Windows.  When I build GDB, even without TUI, I need to
hide libncurses from the configure script in order to build a working
debugger.

> However, when I run: "gdb --tui" from msys2 I get a "TUI mode not
> supported".

I would suggest to debug this: find out where this message is coming
from, and use GDB (without TUI ;-) to investigate the reasons.

> When I run it from DOS (with mingw64 paths in the PATH), it runs but
> I cannot move the text cursor to left arrow and right arrow), and
> even more annoying, I can't use the CTRL+R (history lookup).
> 
> I saw some post about gdb with TUI support on Windows:
> http://migeel.sk/blog/2009/04/15/compiling-gdb-under-windows/
> 
> But it didn't help.
> 
> Do you have any idea how to get it done right?

Eventually, the only way to solve this is to debug the binary you
build.  Find the code that handles the arrow keys and Ctrl-R, and step
through it to understand what's wrong.

It is also worth looking into the second change mentioned by the above
article (although it's very old, and might be no longer applicable):
it seems to hint that GDB uses a pipe to communicate with readline,
which might be one reason for problems, since pipes are notoriously
unportable between Posix and Windows platforms.

Or maybe someone else did build GDB with TUI on Windows, and they will
respond shortly.

Good luck.

Re: building gdb with TUI support on Windows

[Ofir Cohen]

Hi Eli,
Thank you for your prompt response.
Only the windows-termcap.c needed changes.

I was hoping to spare myself debugging gdb's code by getting a good
advice here, but it seems like it's the only way.

It seems like there is something wrong with the keys binding, because
Ctrl+P - works, but up arrow doesn't
Ctrl+D - works, but delete doesn't..

So either I'll get response from someone who has been there before, or
I'll debug it myself as you suggested.

Thanks,
Ofir Cohen

On 26 December 2014 at 10:04, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Fri, 26 Dec 2014 02:13:36 +0200
>> From: Ofir Cohen <ofircohenn@gmail.com>
>>
>> I'm trying to build gdb from source with TUI support on Windows.
>> I'm using msys2 with MinGWx64.
>> It seems non-trivial, and is accompanied by undesired behavior.
>>
>> I'm addressing this mailing list after a long period of trying by myself
>> and because I couldn't find a decent place where this could be solved.
>>
>> I manage to build by commenting out tputs() implementation in
>> gdb/windows-termcap.c
>> (so the ncurses tputs is used instead).
>
> Are you sure this is the only place where you need changes in order to
> use ncurses?  There used to be quite a few places where GDB and
> readline worked around the missing curses library on Windows, and
> those places were never modified to account for ncurses being
> available on Windows.  When I build GDB, even without TUI, I need to
> hide libncurses from the configure script in order to build a working
> debugger.
>
>> However, when I run: "gdb --tui" from msys2 I get a "TUI mode not
>> supported".
>
> I would suggest to debug this: find out where this message is coming
> from, and use GDB (without TUI ;-) to investigate the reasons.
>
>> When I run it from DOS (with mingw64 paths in the PATH), it runs but
>> I cannot move the text cursor to left arrow and right arrow), and
>> even more annoying, I can't use the CTRL+R (history lookup).
>>
>> I saw some post about gdb with TUI support on Windows:
>> http://migeel.sk/blog/2009/04/15/compiling-gdb-under-windows/
>>
>> But it didn't help.
>>
>> Do you have any idea how to get it done right?
>
> Eventually, the only way to solve this is to debug the binary you
> build.  Find the code that handles the arrow keys and Ctrl-R, and step
> through it to understand what's wrong.
>
> It is also worth looking into the second change mentioned by the above
> article (although it's very old, and might be no longer applicable):
> it seems to hint that GDB uses a pipe to communicate with readline,
> which might be one reason for problems, since pipes are notoriously
> unportable between Posix and Windows platforms.
>
> Or maybe someone else did build GDB with TUI on Windows, and they will
> respond shortly.
>
> Good luck.

Re: building gdb with TUI support on Windows

[Eli Zaretskii]

> Date: Sat, 27 Dec 2014 15:52:16 +0200
> From: Ofir Cohen <ofircohenn@gmail.com>
> Cc: gdb@sourceware.org
> 
> It seems like there is something wrong with the keys binding, because
> Ctrl+P - works, but up arrow doesn't 
> Ctrl+D - works, but delete doesn't.. 

If that's your only problem, then the solution should be simple: find
the place where the keyboard keys are interpreted, find out what GDB
gets when you press the PC keys, and simply add them to the dispatch.

> So either I'll get response from someone who has been there before, or I'll
> debug it myself as you suggested. 

I doubt that anyone builds GDB with TUI on Windows.  AFAIR, there was
a suggestion some time ago to remove TUI support altogether.

But you can never know, so waiting a little bit more (accounting for
the holidays) might bring some helpful responses.

Re: building gdb with TUI support on Windows

[Hannes Domani]

Hello


Eli Zaretskii <eliz@gnu.org> schrieb am 15:14 Samstag, 27.Dezember 2014:
> > Date: Sat, 27 Dec 2014 15:52:16 +0200
> > From: Ofir Cohen <ofircohenn@gmail.com>
> > Cc: gdb@sourceware.org
> >
> > It seems like there is something wrong with the keys binding, because
> > Ctrl+P - works, but up arrow doesn't
> > Ctrl+D - works, but delete doesn't..
> 
> If that's your only problem, then the solution should be simple: find
> the place where the keyboard keys are interpreted, find out what GDB
> gets when you press the PC keys, and simply add them to the dispatch.

You might want to check out this link (plus the comments):
http://opensourcepack.blogspot.co.at/2012/02/gdb-74-with-tui-win32.html

> > So either I'll get response from someone who has been there before, or I'll
> > debug it myself as you suggested.
> 
> I doubt that anyone builds GDB with TUI on Windows.

I do.

> AFAIR, there was a suggestion some time ago to remove TUI support altogether.

So the developers don't use it at all themselves?

Re: building gdb with TUI support on Windows

[Eli Zaretskii]

> Date: Sat, 27 Dec 2014 14:39:46 +0000 (UTC)
> From: Hannes Domani <ssbssa@yahoo.de>
> 
> You might want to check out this link (plus the comments):
> http://opensourcepack.blogspot.co.at/2012/02/gdb-74-with-tui-win32.html

Thank.  May I encourage you to report those problems with the patches?
It would be nice to have them upstream (the latest version of GDB is
7.8.1, with 7.9 looming).

> > AFAIR, there was a suggestion some time ago to remove TUI support altogether.
> 
> So the developers don't use it at all themselves?

Can't speak for them.  I certainly don't, I use the Emacs front-end
instead.

Re: building gdb with TUI support on Windows

[Hannes Domani]

Eli Zaretskii <eliz@gnu.org> schrieb am 19:32 Samstag, 27.Dezember 2014:
> > Date: Sat, 27 Dec 2014 14:39:46 +0000 (UTC)
> > From: Hannes Domani <ssbssa@yahoo.de>
> >
> > You might want to check out this link (plus the comments):
> > http://opensourcepack.blogspot.co.at/2012/02/gdb-74-with-tui-win32.html
> 
> Thank.  May I encourage you to report those problems with the patches?
> It would be nice to have them upstream (the latest version of GDB is
> 7.8.1, with 7.9 looming).

I forgot that I only had these problems with ncurses.
Since then I switched to pdcurses, it works much better (+faster) on windows.

I only had to change tputs() a bit.

Re: building gdb with TUI support on Windows

[Ofir Cohen]

Hi Hannes,
Thanks a lot for the reply.

It seems like one has to hack his own way through the code,
and concrete steps / further description will be very helpful in my case.

> I only had to change tputs() a bit.
Could you please describe what changes are required there?
I just commented it out, but I'm not sure that's enough.

> Since then I switched to pdcurses, it works much better (+faster) on windows.
What environment and configuration did you use for building it?
Do you just:
./configure --prefix=/mingw
make
make install

and build gdb (in my case it's msys/msys2)?

Or you needed to hack a little bit more (since PDCurses will not be
found by default by configure)
by adding for example some symbolic links from pdcurses libraries to ncurses?

Thanks,
Ofir Cohen

On 28 December 2014 at 15:58, Hannes Domani <ssbssa@yahoo.de> wrote:
> Eli Zaretskii <eliz@gnu.org> schrieb am 19:32 Samstag, 27.Dezember 2014:
>> > Date: Sat, 27 Dec 2014 14:39:46 +0000 (UTC)
>> > From: Hannes Domani <ssbssa@yahoo.de>
>> >
>> > You might want to check out this link (plus the comments):
>> > http://opensourcepack.blogspot.co.at/2012/02/gdb-74-with-tui-win32.html
>>
>> Thank.  May I encourage you to report those problems with the patches?
>> It would be nice to have them upstream (the latest version of GDB is
>> 7.8.1, with 7.9 looming).
>
> I forgot that I only had these problems with ncurses.
> Since then I switched to pdcurses, it works much better (+faster) on windows.
>
> I only had to change tputs() a bit.

Re: building gdb with TUI support on Windows

[Hannes Domani]

> Ofir Cohen <ofircohenn@gmail.com> schrieb am 17:41 Sonntag, 28.Dezember 2014:
> Hi Hannes,
> Thanks a lot for the reply.
> 
> It seems like one has to hack his own way through the code,
> and concrete steps / further description will be very helpful in my case.
> 
> > I only had to change tputs() a bit.
> Could you please describe what changes are required there?
> I just commented it out, but I'm not sure that's enough.

I just changed it so that it actually does something:

--- a/pdcurses/terminfo.c
+++ b/pdcurses/terminfo.c
@@ -211,5 +211,8 @@ int tputs(const char *str, int affcnt, int (*putfunc)(int))
{
PDC_LOG(("tputs() - called\n"));

-    return ERR;
+    while (*str)
+        putfunc(*str++);
+
+    return 0;
}



> > Since then I switched to pdcurses, it works much better (+faster) on windows.
> What environment and configuration did you use for building it?
> Do you just:
> ./configure --prefix=/mingw
> make
> make install
> 
> and build gdb (in my case it's msys/msys2)?
> 
> Or you needed to hack a little bit more (since PDCurses will not be
> found by default by configure)
> by adding for example some symbolic links from pdcurses libraries to ncurses?

I used the win32/gccwin32.mak:
make -f win32/gccwin32.mak pdcurses.a

After renaming pdcurses.a to libcurses.a, I moved curses.h/term.h/libcurses.a where gdb-configure needed it.

I think that's all.

Re: building gdb with TUI support on Windows

[Ofir Cohen]

Hi Hannes,
I followed your advice, but I get compilation errors.

1) build pdcurses (with patched tputs)
a. copy term.h/curses.h to /mingw64/include and /mingw64/include/ncurses
b. copy libncurses.a  to /mingw64/lib/
1) cd gdb-7.8
2) mkdir build; cd build
3) .././configure --enable-tui --with-expat --build=x86_64-w64-mingw32
4) make
5) from DOS:
a) set PATH=c:\msys64\mingw64\bin\;%PATH%
b) d:\gdb-7.8\build\gdb\gdb --tui

and even tried more to force use the ncurses termcap with:
.././configure --enable-tui --with-curses --with-expat
--build=x86_64-w64-mingw32

But on TUI mode, the left/right/up arrows still don't work.
Neither does the CTRL+R (history lookup).

Though when you quit TUI mode (CTRL +x, a), the arrows start functioning,
and then when you go back to TUI mode (same keys combination), they don't work.

Do the arrow keys work for you when you're in TUI mode?
What do you think is the problem?

Note: the samples that come with pdcurses work, and the arrow keys
function there.
So it seems to be a gdb per se problem, and not some lack of support
from the library.

Thanks,
Ofir Cohen

On 28 December 2014 at 19:08, Hannes Domani <ssbssa@yahoo.de> wrote:
>> Ofir Cohen <ofircohenn@gmail.com> schrieb am 17:41 Sonntag, 28.Dezember 2014:
>> Hi Hannes,
>> Thanks a lot for the reply.
>>
>> It seems like one has to hack his own way through the code,
>> and concrete steps / further description will be very helpful in my case.
>>
>> > I only had to change tputs() a bit.
>> Could you please describe what changes are required there?
>> I just commented it out, but I'm not sure that's enough.
>
> I just changed it so that it actually does something:
>
> --- a/pdcurses/terminfo.c
> +++ b/pdcurses/terminfo.c
> @@ -211,5 +211,8 @@ int tputs(const char *str, int affcnt, int (*putfunc)(int))
> {
> PDC_LOG(("tputs() - called\n"));
>
> -    return ERR;
> +    while (*str)
> +        putfunc(*str++);
> +
> +    return 0;
> }
>
>
>
>> > Since then I switched to pdcurses, it works much better (+faster) on windows.
>> What environment and configuration did you use for building it?
>> Do you just:
>> ./configure --prefix=/mingw
>> make
>> make install
>>
>> and build gdb (in my case it's msys/msys2)?
>>
>> Or you needed to hack a little bit more (since PDCurses will not be
>> found by default by configure)
>> by adding for example some symbolic links from pdcurses libraries to ncurses?
>
> I used the win32/gccwin32.mak:
> make -f win32/gccwin32.mak pdcurses.a
>
> After renaming pdcurses.a to libcurses.a, I moved curses.h/term.h/libcurses.a where gdb-configure needed it.
>
> I think that's all.

Re: building gdb with TUI support on Windows

[Hannes Domani]

Ofir Cohen <ofircohenn@gmail.com> schrieb am 0:34 Montag, 29.Dezember 2014:
> Hi Hannes,
> I followed your advice, but I get compilation errors.
> 
> 1) build pdcurses (with patched tputs)
> a. copy term.h/curses.h to /mingw64/include and /mingw64/include/ncurses
> b. copy libncurses.a  to /mingw64/lib/
> 1) cd gdb-7.8
> 2) mkdir build; cd build
> 3) .././configure --enable-tui --with-expat --build=x86_64-w64-mingw32
> 4) make
> 5) from DOS:
> a) set PATH=c:\msys64\mingw64\bin\;%PATH%
> b) d:\gdb-7.8\build\gdb\gdb --tui
> 
> and even tried more to force use the ncurses termcap with:
> .././configure --enable-tui --with-curses --with-expat
> --build=x86_64-w64-mingw32
> 
> But on TUI mode, the left/right/up arrows still don't work.
> Neither does the CTRL+R (history lookup).

So you had some compilation errors which you fixed yourself?

> Though when you quit TUI mode (CTRL +x, a), the arrows start functioning,
> and then when you go back to TUI mode (same keys combination), they don't work.
> 
> Do the arrow keys work for you when you're in TUI mode?
> What do you think is the problem?
> 
> Note: the samples that come with pdcurses work, and the arrow keys
> function there.
> So it seems to be a gdb per se problem, and not some lack of support
> from the library.

I just retried CTRL+R and the arrow keys in TUI and normal mode, all works.
You are aware that with the arrow keys in TUI mode you move in the source
window, and not in the history?

But I can't explain why CTRL+R doesn't work for you.
Does it work in normal mode?

My build uses libiconv as well (to display unicode strings), but I don't think
this makes any difference for this case.

Re: building gdb with TUI support on Windows

[Ofir Cohen]

Hi Hannes,
Thanks again for the reply =].

> You are aware that with the arrow keys in TUI mode you move in the source
window, and not in the history?

Yes, ofc, I'm therefore moving the window focus from source to the
interpreter's CLI window (Ctrl+x, o),
and only then issue the arrow up/down/left/right commands.
Unfortunately, it doesn't work, I have to get out of TUI mode (Ctrl+x,
a), to make the arrow keys respond.

On Linux, when you do the above mentioned steps, it works flawlessly.

A shallow investigation, debugging of gdb with gdb, showed that
wgetch() function (deep in the call-stack, invoked indirectly by
stdin_event_handler), is blocking and doesn't return when the
arrow-keys are issued.

When gdb is not in TUI mode, however, getch() is called instead,
returns promptly and issues
the associated dispatch handler.

I'm interested in knowing how does it work for you,
and/or comparing the Linux flow (step-by-step debugging of gdb) with
the Windows's one.

Thanks,
Ofir Cohen

On 29 December 2014 at 02:41, Hannes Domani <ssbssa@yahoo.de> wrote:
> Ofir Cohen <ofircohenn@gmail.com> schrieb am 0:34 Montag, 29.Dezember 2014:
>> Hi Hannes,
>> I followed your advice, but I get compilation errors.
>>
>> 1) build pdcurses (with patched tputs)
>> a. copy term.h/curses.h to /mingw64/include and /mingw64/include/ncurses
>> b. copy libncurses.a  to /mingw64/lib/
>> 1) cd gdb-7.8
>> 2) mkdir build; cd build
>> 3) .././configure --enable-tui --with-expat --build=x86_64-w64-mingw32
>> 4) make
>> 5) from DOS:
>> a) set PATH=c:\msys64\mingw64\bin\;%PATH%
>> b) d:\gdb-7.8\build\gdb\gdb --tui
>>
>> and even tried more to force use the ncurses termcap with:
>> .././configure --enable-tui --with-curses --with-expat
>> --build=x86_64-w64-mingw32
>>
>> But on TUI mode, the left/right/up arrows still don't work.
>> Neither does the CTRL+R (history lookup).
>
> So you had some compilation errors which you fixed yourself?
>
>> Though when you quit TUI mode (CTRL +x, a), the arrows start functioning,
>> and then when you go back to TUI mode (same keys combination), they don't work.
>>
>> Do the arrow keys work for you when you're in TUI mode?
>> What do you think is the problem?
>>
>> Note: the samples that come with pdcurses work, and the arrow keys
>> function there.
>> So it seems to be a gdb per se problem, and not some lack of support
>> from the library.
>
> I just retried CTRL+R and the arrow keys in TUI and normal mode, all works.
> You are aware that with the arrow keys in TUI mode you move in the source
> window, and not in the history?
>
> But I can't explain why CTRL+R doesn't work for you.
> Does it work in normal mode?
>
> My build uses libiconv as well (to display unicode strings), but I don't think
> this makes any difference for this case.

Re: building gdb with TUI support on Windows

[Hannes Domani]

Ofir Cohen <ofircohenn@gmail.com> schrieb am 16:28 Montag, 29.Dezember 2014:
> Hi Hannes,
> Thanks again for the reply =].
> 
> > You are aware that with the arrow keys in TUI mode you move in the source
> window, and not in the history?
> 
> Yes, ofc, I'm therefore moving the window focus from source to the
> interpreter's CLI window (Ctrl+x, o),
> and only then issue the arrow up/down/left/right commands.
> Unfortunately, it doesn't work, I have to get out of TUI mode (Ctrl+x,
> a), to make the arrow keys respond.
> 
> On Linux, when you do the above mentioned steps, it works flawlessly.
> 
> A shallow investigation, debugging of gdb with gdb, showed that
> wgetch() function (deep in the call-stack, invoked indirectly by
> stdin_event_handler), is blocking and doesn't return when the
> arrow-keys are issued.
> 
> When gdb is not in TUI mode, however, getch() is called instead,
> returns promptly and issues
> the associated dispatch handler.

I forgot you could move the focus to the CLI window.
You're right, the arrow keys don't work there.

I'm always using CTRL+P/N/F/B instead of the arrow keys,
regardless of if I'm in TUI mode or not.

> I'm interested in knowing how does it work for you,
> and/or comparing the Linux flow (step-by-step debugging of gdb) with
> the Windows's one.

Except that CTRL+C might not work, I don't really have any problems.

Re: building gdb with TUI support on Windows

[Hannes Domani]

Ofir Cohen <ofircohenn@gmail.com> schrieb am 16:28 Montag, 29.Dezember 2014:
> Hi Hannes,
> Thanks again for the reply =].
> 
> > You are aware that with the arrow keys in TUI mode you move in the source
> window, and not in the history?
> 
> Yes, ofc, I'm therefore moving the window focus from source to the
> interpreter's CLI window (Ctrl+x, o),
> and only then issue the arrow up/down/left/right commands.
> Unfortunately, it doesn't work, I have to get out of TUI mode (Ctrl+x,
> a), to make the arrow keys respond.
> 
> On Linux, when you do the above mentioned steps, it works flawlessly.
> 
> A shallow investigation, debugging of gdb with gdb, showed that
> wgetch() function (deep in the call-stack, invoked indirectly by
> stdin_event_handler), is blocking and doesn't return when the
> arrow-keys are issued.
> 
> When gdb is not in TUI mode, however, getch() is called instead,
> returns promptly and issues
> the associated dispatch handler.

I figured out the problem here.
When the CLI get the focus, the keypad is disabled. This means wgetch()
should return special keys as escape sequences (like getch() does), and not
as a single value (e.g. KEY_LEFT).
pdcurses instead ignores special keys completely if keypad is disabled.

I've made the following changes to recreate this behavior for some keys:

--- a/pdcurses/getch.c	2008-07-13 18:08:18.000000000 +0200
+++ b/pdcurses/getch.c	2014-12-30 16:46:45.604498500 +0100
@@ -2,6 +2,11 @@

#include <curspriv.h>

+#ifdef _WIN32
+#include <windows.h>
+extern HANDLE pdc_con_in;
+#endif
+
RCSID("$Id: getch.c,v 1.72 2008/07/13 16:08:18 wmcbrine Exp $")

/*man-start**************************************************************
@@ -238,7 +243,55 @@
/* filter special keys if not in keypad mode */

if (!win->_use_keypad)
+            {
+#ifdef _WIN32
+                char backhalf = 0;
+                switch (key)
+                {
+                case KEY_UP:
+                    backhalf = 'H';
+                    break;
+                case KEY_DOWN:
+                    backhalf = 'P';
+                    break;
+                case KEY_LEFT:
+                    backhalf = 'K';
+                    break;
+                case KEY_RIGHT:
+                    backhalf = 'M';
+                    break;
+                case KEY_HOME:
+                    backhalf = 'G';
+                    break;
+                case KEY_END:
+                    backhalf = 'O';
+                    break;
+                case KEY_DC:
+                    backhalf = 'S';
+                    break;
+                case KEY_IC:
+                    backhalf = 'R';
+                    break;
+                }
+                if (backhalf)
+                {
+                    INPUT_RECORD ir;
+                    ir.EventType = KEY_EVENT;
+                    ir.Event.KeyEvent.bKeyDown = TRUE;
+                    ir.Event.KeyEvent.dwControlKeyState = 0;
+                    ir.Event.KeyEvent.uChar.UnicodeChar = backhalf;
+                    ir.Event.KeyEvent.wRepeatCount = 1;
+                    ir.Event.KeyEvent.wVirtualKeyCode = backhalf;
+                    ir.Event.KeyEvent.wVirtualScanCode =
+                        MapVirtualKey(backhalf, MAPVK_VK_TO_VSC);
+                    DWORD written;
+                    WriteConsoleInput(pdc_con_in, &ir, 1, &written);
+                    return 0xe0;
+                }
+#endif
+
key = -1;
+            }

/* filter mouse events; translate mouse clicks in the slk 
area to function keys */

Re: building gdb with TUI support on Windows

[Ofir Cohen]

Hi Hannes,
Holy smokes, just tested and it works ;-)
Thanks a lot for sharing this useful patch.

Sorry for the ignorance, but what does this keypad mode mean and what
is its role?
Moreover, is this default behavior intended?
(as both PDCurses and true libncurses fail, each in its own (unique?) way).

Bonus question: in your opinion, is screen clear possible on Windows? (CTRL+L)

Thanks a lot again,
you've just made my debugging experience way more fun and productive!

- Ofir Cohen

On 30 December 2014 at 21:15, Hannes Domani <ssbssa@yahoo.de> wrote:
> Ofir Cohen <ofircohenn@gmail.com> schrieb am 16:28 Montag, 29.Dezember 2014:
>> Hi Hannes,
>> Thanks again for the reply =].
>>
>> > You are aware that with the arrow keys in TUI mode you move in the source
>> window, and not in the history?
>>
>> Yes, ofc, I'm therefore moving the window focus from source to the
>> interpreter's CLI window (Ctrl+x, o),
>> and only then issue the arrow up/down/left/right commands.
>> Unfortunately, it doesn't work, I have to get out of TUI mode (Ctrl+x,
>> a), to make the arrow keys respond.
>>
>> On Linux, when you do the above mentioned steps, it works flawlessly.
>>
>> A shallow investigation, debugging of gdb with gdb, showed that
>> wgetch() function (deep in the call-stack, invoked indirectly by
>> stdin_event_handler), is blocking and doesn't return when the
>> arrow-keys are issued.
>>
>> When gdb is not in TUI mode, however, getch() is called instead,
>> returns promptly and issues
>> the associated dispatch handler.
>
> I figured out the problem here.
> When the CLI get the focus, the keypad is disabled. This means wgetch()
> should return special keys as escape sequences (like getch() does), and not
> as a single value (e.g. KEY_LEFT).
> pdcurses instead ignores special keys completely if keypad is disabled.
>
> I've made the following changes to recreate this behavior for some keys:
>
> --- a/pdcurses/getch.c  2008-07-13 18:08:18.000000000 +0200
> +++ b/pdcurses/getch.c  2014-12-30 16:46:45.604498500 +0100
> @@ -2,6 +2,11 @@
>
> #include <curspriv.h>
>
> +#ifdef _WIN32
> +#include <windows.h>
> +extern HANDLE pdc_con_in;
> +#endif
> +
> RCSID("$Id: getch.c,v 1.72 2008/07/13 16:08:18 wmcbrine Exp $")
>
> /*man-start**************************************************************
> @@ -238,7 +243,55 @@
> /* filter special keys if not in keypad mode */
>
> if (!win->_use_keypad)
> +            {
> +#ifdef _WIN32
> +                char backhalf = 0;
> +                switch (key)
> +                {
> +                case KEY_UP:
> +                    backhalf = 'H';
> +                    break;
> +                case KEY_DOWN:
> +                    backhalf = 'P';
> +                    break;
> +                case KEY_LEFT:
> +                    backhalf = 'K';
> +                    break;
> +                case KEY_RIGHT:
> +                    backhalf = 'M';
> +                    break;
> +                case KEY_HOME:
> +                    backhalf = 'G';
> +                    break;
> +                case KEY_END:
> +                    backhalf = 'O';
> +                    break;
> +                case KEY_DC:
> +                    backhalf = 'S';
> +                    break;
> +                case KEY_IC:
> +                    backhalf = 'R';
> +                    break;
> +                }
> +                if (backhalf)
> +                {
> +                    INPUT_RECORD ir;
> +                    ir.EventType = KEY_EVENT;
> +                    ir.Event.KeyEvent.bKeyDown = TRUE;
> +                    ir.Event.KeyEvent.dwControlKeyState = 0;
> +                    ir.Event.KeyEvent.uChar.UnicodeChar = backhalf;
> +                    ir.Event.KeyEvent.wRepeatCount = 1;
> +                    ir.Event.KeyEvent.wVirtualKeyCode = backhalf;
> +                    ir.Event.KeyEvent.wVirtualScanCode =
> +                        MapVirtualKey(backhalf, MAPVK_VK_TO_VSC);
> +                    DWORD written;
> +                    WriteConsoleInput(pdc_con_in, &ir, 1, &written);
> +                    return 0xe0;
> +                }
> +#endif
> +
> key = -1;
> +            }
>
> /* filter mouse events; translate mouse clicks in the slk
> area to function keys */

Re: building gdb with TUI support on Windows

[Hannes Domani]

Ofir Cohen <ofircohenn@gmail.com> schrieb am 21:11 Dienstag, 30.Dezember 2014:
> Sorry for the ignorance, but what does this keypad mode mean and what
> is its role?
> Moreover, is this default behavior intended?
> (as both PDCurses and true libncurses fail, each in its own (unique?) way).

For special keys, getch() has to be called multiple times and it returns
part of the an escape sequence each call (e.g. 0xe0 + 'K' for left arrow).

When keypad is enabled, wgetch() returns a single integer (e.g. KEY_LEFT).
When disabled, it should return the escape sequence as getch() does.

pdcurses is missing this, mayge the developer didn't see the usefulness.

I found the information about wgetch/keypad here:
http://linux.die.net/man/3/wgetch

> Bonus question: in your opinion, is screen clear possible on Windows? (CTRL+L)

In TUI mode CTRL+L redraws the screen.
Should it clear the screen in normal mode? I don't really know.
If you mean that, I can look into it.

Re: building gdb with TUI support on Windows

[Eli Zaretskii]

> Date: Tue, 30 Dec 2014 20:39:08 +0000 (UTC)
> From: Hannes Domani <ssbssa@yahoo.de>
> 
> For special keys, getch() has to be called multiple times and it returns
> part of the an escape sequence each call (e.g. 0xe0 + 'K' for left arrow).
> 
> When keypad is enabled, wgetch() returns a single integer (e.g. KEY_LEFT).
> When disabled, it should return the escape sequence as getch() does.

Sorry, I'm missing something here.  AFAIK, "gdb -tui" doesn't call
'getch', it calls 'wgetch'.  Are you saying that when keypad is
disabled, GDB (or readline) somehow _expect_ to see escape sequences?
If not, I don't see why would the curses library need to start sending
escape sequences in that mode, it could simply continue sending single
keys, as it does in the keypad mode.  What am I missing?

> In TUI mode CTRL+L redraws the screen.
> Should it clear the screen in normal mode? I don't really know.
> If you mean that, I can look into it.

In the normal mode, Ctrl-L invokes a readline function, which probably
does nothing, because the curses library probably defines a null
sequence for "clear page".

Re: building gdb with TUI support on Windows

[Hannes Domani]

Eli Zaretskii <eliz@gnu.org> schrieb am 17:34 Mittwoch, 31.Dezember 2014:
> > For special keys, getch() has to be called multiple times and it returns
> > part of the an escape sequence each call (e.g. 0xe0 + 'K' for left arrow).
> >
> > When keypad is enabled, wgetch() returns a single integer (e.g. KEY_LEFT).
> > When disabled, it should return the escape sequence as getch() does.
> 
> Sorry, I'm missing something here.  AFAIK, "gdb -tui" doesn't call
> 'getch', it calls 'wgetch'.  Are you saying that when keypad is
> disabled, GDB (or readline) somehow _expect_ to see escape sequences?
> If not, I don't see why would the curses library need to start sending
> escape sequences in that mode, it could simply continue sending single
> keys, as it does in the keypad mode.  What am I missing?

Isn't that the whole point of the keypad option?
At least that's how I understood this documentation:
http://linux.die.net/man/3/keypad



> > In TUI mode CTRL+L redraws the screen.
> > Should it clear the screen in normal mode? I don't really know.
> > If you mean that, I can look into it.
> 
> In the normal mode, Ctrl-L invokes a readline function, which probably
> does nothing, because the curses library probably defines a null
> sequence for "clear page".

Yes, that's what I found as well.

Re: building gdb with TUI support on Windows

[Eli Zaretskii]

> Date: Thu, 1 Jan 2015 12:27:27 +0000 (UTC)
> From: Hannes Domani <ssbssa@yahoo.de>
> 
> Eli Zaretskii <eliz@gnu.org> schrieb am 17:34 Mittwoch, 31.Dezember 2014:
> > > For special keys, getch() has to be called multiple times and it returns
> > > part of the an escape sequence each call (e.g. 0xe0 + 'K' for left arrow).
> > >
> > > When keypad is enabled, wgetch() returns a single integer (e.g. KEY_LEFT).
> > > When disabled, it should return the escape sequence as getch() does.
> > 
> > Sorry, I'm missing something here.  AFAIK, "gdb -tui" doesn't call
> > 'getch', it calls 'wgetch'.  Are you saying that when keypad is
> > disabled, GDB (or readline) somehow _expect_ to see escape sequences?
> > If not, I don't see why would the curses library need to start sending
> > escape sequences in that mode, it could simply continue sending single
> > keys, as it does in the keypad mode.  What am I missing?
> 
> Isn't that the whole point of the keypad option?
> At least that's how I understood this documentation:
> http://linux.die.net/man/3/keypad

That's just a man page from ncurses (which was what I read to learn
about the function), and it doesn't in any way preclude the
possibility that wgetch still returns single keys, rather than the
full escape sequence.

Put another way, if after the call to 'keypad', wgetch still returns a
single value, "gdb -tui" should still work.  The problem could only
happen if wgetch returns ERR or doesn't return anything.

Anyway, I asked on the ncurses list about this, let's see what they
reply.

Re: building gdb with TUI support on Windows

[Ofir Cohen]

Hi Hannes,

> In TUI mode CTRL+L redraws the screen.
> Should it clear the screen in normal mode? I don't really know.
> If you mean that, I can look into it.
That's definitely not critical, I'm more interested in getting "Ctrl +
Arrow Left/Right"
keys combination, work.

In DOS, "Ctrl + Arrow-Left" skips an entire word (like Alt+B/F on bash).
The key sequence of: Esc + b, or Esc + f, seems to accomplish that in gdb.

Do you have any idea how to make Ctrl+Left/Right to behave like Esc+b/f?

Do I need to intercept these control codes / keys in curses?

Thanks again!
- Ofir


On 30 December 2014 at 22:39, Hannes Domani <ssbssa@yahoo.de> wrote:
> Ofir Cohen <ofircohenn@gmail.com> schrieb am 21:11 Dienstag, 30.Dezember 2014:
>> Sorry for the ignorance, but what does this keypad mode mean and what
>> is its role?
>> Moreover, is this default behavior intended?
>> (as both PDCurses and true libncurses fail, each in its own (unique?) way).
>
> For special keys, getch() has to be called multiple times and it returns
> part of the an escape sequence each call (e.g. 0xe0 + 'K' for left arrow).
>
> When keypad is enabled, wgetch() returns a single integer (e.g. KEY_LEFT).
> When disabled, it should return the escape sequence as getch() does.
>
> pdcurses is missing this, mayge the developer didn't see the usefulness.
>
> I found the information about wgetch/keypad here:
> http://linux.die.net/man/3/wgetch
>
>> Bonus question: in your opinion, is screen clear possible on Windows? (CTRL+L)
>
> In TUI mode CTRL+L redraws the screen.
> Should it clear the screen in normal mode? I don't really know.
> If you mean that, I can look into it.

Re: building gdb with TUI support on Windows

[Hannes Domani]

Ofir Cohen <ofircohenn@gmail.com> schrieb am 22:12 Mittwoch, 31.Dezember 2014:
> In DOS, "Ctrl + Arrow-Left" skips an entire word (like Alt+B/F on bash).
> The key sequence of: Esc + b, or Esc + f, seems to accomplish that in gdb.
> 
> Do you have any idea how to make Ctrl+Left/Right to behave like Esc+b/f?
> 
> Do I need to intercept these control codes / keys in curses?

Add this to gdb:

--- a/readline/readline.c    2015-01-01 14:47:03.999708300 +0100
+++ b/readline/readline.c    2015-01-01 14:47:11.399718700 +0100
@@ -1163,6 +1163,9 @@
    rl_bind_keyseq_if_unbound ("\340O", rl_end_of_line);
    rl_bind_keyseq_if_unbound ("\340S", rl_delete);
    rl_bind_keyseq_if_unbound ("\340R", rl_overwrite_mode);
+
+  rl_bind_keyseq_if_unbound ("\340s", rl_backward_word);  /* ctrl-left  */
+  rl_bind_keyseq_if_unbound ("\340t", rl_forward_word);    /* ctrl-right */
#endif

   _rl_keymap = xkeymap;



And this to pdcurses:

--- a/pdcurses/getch.c    2015-01-01 14:56:25.870495000 +0100
+++ b/pdcurses/getch.c    2015-01-01 14:56:33.250505300 +0100
@@ -272,6 +272,12 @@
                  case KEY_IC:
                      backhalf = 'R';
                      break;
+                case CTL_LEFT:
+                    backhalf = 's';
+                    break;
+                case CTL_RIGHT:
+                    backhalf = 't';
+                    break;
                  }
                  if (backhalf)
                  {

Re: building gdb with TUI support on Windows

[Ofir Cohen]

Hi Hannes,
You are literally t-h-e_ b-e-s-t!

Thanks a lot :-)!!!!!
Ofir

On 1 January 2015 at 16:26, Hannes Domani <ssbssa@yahoo.de> wrote:
> Ofir Cohen <ofircohenn@gmail.com> schrieb am 22:12 Mittwoch, 31.Dezember 2014:
>> In DOS, "Ctrl + Arrow-Left" skips an entire word (like Alt+B/F on bash).
>> The key sequence of: Esc + b, or Esc + f, seems to accomplish that in gdb.
>>
>> Do you have any idea how to make Ctrl+Left/Right to behave like Esc+b/f?
>>
>> Do I need to intercept these control codes / keys in curses?
>
> Add this to gdb:
>
> --- a/readline/readline.c    2015-01-01 14:47:03.999708300 +0100
> +++ b/readline/readline.c    2015-01-01 14:47:11.399718700 +0100
> @@ -1163,6 +1163,9 @@
>     rl_bind_keyseq_if_unbound ("\340O", rl_end_of_line);
>     rl_bind_keyseq_if_unbound ("\340S", rl_delete);
>     rl_bind_keyseq_if_unbound ("\340R", rl_overwrite_mode);
> +
> +  rl_bind_keyseq_if_unbound ("\340s", rl_backward_word);  /* ctrl-left  */
> +  rl_bind_keyseq_if_unbound ("\340t", rl_forward_word);    /* ctrl-right */
> #endif
>
>    _rl_keymap = xkeymap;
>
>
>
> And this to pdcurses:
>
> --- a/pdcurses/getch.c    2015-01-01 14:56:25.870495000 +0100
> +++ b/pdcurses/getch.c    2015-01-01 14:56:33.250505300 +0100
> @@ -272,6 +272,12 @@
>                   case KEY_IC:
>                       backhalf = 'R';
>                       break;
> +                case CTL_LEFT:
> +                    backhalf = 's';
> +                    break;
> +                case CTL_RIGHT:
> +                    backhalf = 't';
> +                    break;
>                   }
>                   if (backhalf)
>                   {

Re: building gdb with TUI support on Windows

[Eli Zaretskii]

> Date: Thu, 1 Jan 2015 14:26:08 +0000 (UTC)
> From: Hannes Domani <ssbssa@yahoo.de>
> 
> Ofir Cohen <ofircohenn@gmail.com> schrieb am 22:12 Mittwoch, 31.Dezember 2014:
> > In DOS, "Ctrl + Arrow-Left" skips an entire word (like Alt+B/F on bash).
> > The key sequence of: Esc + b, or Esc + f, seems to accomplish that in gdb.
> > 
> > Do you have any idea how to make Ctrl+Left/Right to behave like Esc+b/f?
> > 
> > Do I need to intercept these control codes / keys in curses?
> 
> Add this to gdb:
> 
> --- a/readline/readline.c    2015-01-01 14:47:03.999708300 +0100
> +++ b/readline/readline.c    2015-01-01 14:47:11.399718700 +0100
> @@ -1163,6 +1163,9 @@
>     rl_bind_keyseq_if_unbound ("\340O", rl_end_of_line);
>     rl_bind_keyseq_if_unbound ("\340S", rl_delete);
>     rl_bind_keyseq_if_unbound ("\340R", rl_overwrite_mode);
> +
> +  rl_bind_keyseq_if_unbound ("\340s", rl_backward_word);  /* ctrl-left  */
> +  rl_bind_keyseq_if_unbound ("\340t", rl_forward_word);    /* ctrl-right */
> #endif
> 
>    _rl_keymap = xkeymap;
> 
> 
> 
> And this to pdcurses:
> 
> --- a/pdcurses/getch.c    2015-01-01 14:56:25.870495000 +0100
> +++ b/pdcurses/getch.c    2015-01-01 14:56:33.250505300 +0100
> @@ -272,6 +272,12 @@
>                   case KEY_IC:
>                       backhalf = 'R';
>                       break;
> +                case CTL_LEFT:
> +                    backhalf = 's';
> +                    break;
> +                case CTL_RIGHT:
> +                    backhalf = 't';
> +                    break;
>                   }
>                   if (backhalf)
>                   {

And the following magic in my ~/.inputrc does the same (and a bit
more) without any source-level changes:

  set convert-meta off
  "\340\163": backward-word               # Ctrl-left
  "\340\164": forward-word                # Ctrl-right
  "\340\223": kill-word                   # Ctrl-Delete
  "\340\165": kill-line                   # Ctrl-End

Re: building gdb with TUI support on Windows

[Ofir Cohen]

Hi Eli,
Thanks for sharing.

I launch gdb from DOS, using:
1) set PATH=c:\msys64\mingw64\bin;%PATH%
2) c:\gdb\build\gdb\gdb --tui

When launching from DOS, how does it find ~/.inputrc?
Will the following work:
1. Set HOME=c:/temp/
2. populate c:/temp/.inputrc with your contents (for example)
3. Launch gdb

?

Will readline successfully locate the DOS path to ~/.inputrc ?

Thanks,
Ofir Cohen

On 1 January 2015 at 17:46, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Thu, 1 Jan 2015 14:26:08 +0000 (UTC)
>> From: Hannes Domani <ssbssa@yahoo.de>
>>
>> Ofir Cohen <ofircohenn@gmail.com> schrieb am 22:12 Mittwoch, 31.Dezember 2014:
>> > In DOS, "Ctrl + Arrow-Left" skips an entire word (like Alt+B/F on bash).
>> > The key sequence of: Esc + b, or Esc + f, seems to accomplish that in gdb.
>> >
>> > Do you have any idea how to make Ctrl+Left/Right to behave like Esc+b/f?
>> >
>> > Do I need to intercept these control codes / keys in curses?
>>
>> Add this to gdb:
>>
>> --- a/readline/readline.c    2015-01-01 14:47:03.999708300 +0100
>> +++ b/readline/readline.c    2015-01-01 14:47:11.399718700 +0100
>> @@ -1163,6 +1163,9 @@
>>     rl_bind_keyseq_if_unbound ("\340O", rl_end_of_line);
>>     rl_bind_keyseq_if_unbound ("\340S", rl_delete);
>>     rl_bind_keyseq_if_unbound ("\340R", rl_overwrite_mode);
>> +
>> +  rl_bind_keyseq_if_unbound ("\340s", rl_backward_word);  /* ctrl-left  */
>> +  rl_bind_keyseq_if_unbound ("\340t", rl_forward_word);    /* ctrl-right */
>> #endif
>>
>>    _rl_keymap = xkeymap;
>>
>>
>>
>> And this to pdcurses:
>>
>> --- a/pdcurses/getch.c    2015-01-01 14:56:25.870495000 +0100
>> +++ b/pdcurses/getch.c    2015-01-01 14:56:33.250505300 +0100
>> @@ -272,6 +272,12 @@
>>                   case KEY_IC:
>>                       backhalf = 'R';
>>                       break;
>> +                case CTL_LEFT:
>> +                    backhalf = 's';
>> +                    break;
>> +                case CTL_RIGHT:
>> +                    backhalf = 't';
>> +                    break;
>>                   }
>>                   if (backhalf)
>>                   {
>
> And the following magic in my ~/.inputrc does the same (and a bit
> more) without any source-level changes:
>
>   set convert-meta off
>   "\340\163": backward-word               # Ctrl-left
>   "\340\164": forward-word                # Ctrl-right
>   "\340\223": kill-word                   # Ctrl-Delete
>   "\340\165": kill-line                   # Ctrl-End

Re: building gdb with TUI support on Windows

[Eli Zaretskii]

> Date: Thu, 1 Jan 2015 18:33:35 +0200
> From: Ofir Cohen <ofircohenn@gmail.com>
> Cc: Hannes Domani <ssbssa@yahoo.de>, "gdb@sourceware.org" <gdb@sourceware.org>
> 
> I launch gdb from DOS, using:
> 1) set PATH=c:\msys64\mingw64\bin;%PATH%
> 2) c:\gdb\build\gdb\gdb --tui
> 
> When launching from DOS, how does it find ~/.inputrc?
> Will the following work:
> 1. Set HOME=c:/temp/
> 2. populate c:/temp/.inputrc with your contents (for example)
> 3. Launch gdb
> 
> ?
> 
> Will readline successfully locate the DOS path to ~/.inputrc ?

Sure, why not?  It works for me.

Re: building gdb with TUI support on Windows

[Joel Sherrill]

On January 1, 2015 10:42:45 AM CST, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Thu, 1 Jan 2015 18:33:35 +0200
>> From: Ofir Cohen <ofircohenn@gmail.com>
>> Cc: Hannes Domani <ssbssa@yahoo.de>, "gdb@sourceware.org"
><gdb@sourceware.org>
>> 
>> I launch gdb from DOS, using:
>> 1) set PATH=c:\msys64\mingw64\bin;%PATH%
>> 2) c:\gdb\build\gdb\gdb --tui
>> 
>> When launching from DOS, how does it find ~/.inputrc?
>> Will the following work:
>> 1. Set HOME=c:/temp/
>> 2. populate c:/temp/.inputrc with your contents (for example)
>> 3. Launch gdb
>> 
>> ?
>> 
>> Will readline successfully locate the DOS path to ~/.inputrc ?
>
>Sure, why not?  It works for me.

This sounds like a workable solution but it requires each user to do this. Will this be documented? 

The other solution fixes it without any other user being impacted.

Just pointing out there is a difference.

--joel

Re: building gdb with TUI support on Windows

[Eli Zaretskii]

> From: Joel Sherrill <joel.sherrill@oarcorp.com>
> Date: Thu, 1 Jan 2015 10:48:44 -0600
> CC: "ssbssa@yahoo.de" <ssbssa@yahoo.de>,"gdb@sourceware.org" <gdb@sourceware.org>
> 
> The other solution fixes it without any other user being impacted.

Only if the change will be submitted to the Readline maintainers.
Otherwise, each user will have to patch their sources, and do it for
each new version of GDB.

Re: building gdb with TUI support on Windows

[Ofir Cohen]

Hi Eli,
Thank you for your response.

Retrieving the key sequence is trivial indeed.

I have submitted a bug for this:
Bug 17774 - gdb on Windows TUI mode: arrow keys do not work
https://sourceware.org/bugzilla/show_bug.cgi?id=17774

Once you get a reply from the ncurses mailing list, I would appreciate if you
could send a notification to this mail thread, as well as update the bug so
we could track and fix this.

The wgetch() not returning is a blocker for the fix (at least for PDCurses),
but sure what happens with ncurses.

Once we get the curses fix for windows, and/or the key bindings
settings for readline,
we could upstream the fix.

I am really pleased with thee responsiveness of you and Hannes,
which allowed me to get it working and save lots of time, thanks again.

- Ofir Cohen

On 1 January 2015 at 20:12, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Thu, 1 Jan 2015 19:31:43 +0200
>> From: Ofir Cohen <ofircohenn@gmail.com>
>>
>> Are these codes/magic numbers OS/console-specific?
>> e.g. "\340\163": backward-word               # Ctrl-left
>
> Those are the sequences produced by the Windows console when you press
> those keys.
>
>> Could you please provide pointers that map keyboard keys to codes?
>
> I don't have the full table.  I produced these few by setting a
> breakpoint in rl_getc (a function in Readline which reads the keys),
> and printing what it reads when I press a key.
>
> It is also easy to write a simple program that will display the
> sequence given a keypress.
>
> I'm quite sure you can find the information floating around, though.
> This page looks promising:
>
>   http://www.quadibloc.com/comp/scan.htm
>
>> As this might get rejected / deemed meaningless to the maintainers, or
>> take a lot
>> of time, I think it would be nice if we could:
>>
>> 1. Have next releases of gdb packaged with a sample .inputrc file
>>     e.g. ".windows_console_samle_inputrc"
>>
>>     that provides the most commonly needed/used key-bindings.
>>
>> 2. Provide a hint about this file in the README file / somewhere obvious.
>>
>> After all, I believe I'm not the only keyboard junkie in the world ;-).
>
> But everyone uses Google ;-) So finding this discussion will be easy.
>
> The problem with providing a sample .inputrc with GDB is that this
> file is used not just by GDB, but by any application that uses the
> Readline library.

Re: building gdb with TUI support on Windows

[Sergio Durigan Junior]

On Saturday, December 27 2014, Hannes Domani wrote:

>> AFAIR, there was a suggestion some time ago to remove TUI support altogether.
>
> So the developers don't use it at all themselves?

I use TUI a lot, and I know other developers do as well.  I don't
remember the proposal to remove TUI, and recently we have been receiving
some nice patches to fix issues on it.

-- 
Sergio
GPG key ID: 0x65FC5E36
Please send encrypted e-mail if possible
http://sergiodj.net/

Re: building gdb with TUI support on Windows

[Joel Brobecker]

> >> AFAIR, there was a suggestion some time ago to remove TUI support
> >> altogether.
> >
> > So the developers don't use it at all themselves?
> 
> I use TUI a lot, and I know other developers do as well.  I don't
> remember the proposal to remove TUI, and recently we have been receiving
> some nice patches to fix issues on it.

I might have mentioned the idea a few years back, but it was
very quickly dismissed ;-).

-- 
Joel

Re: building gdb with TUI support on Windows

[Joel Sherrill]

On December 28, 2014 8:43:05 PM CST, Joel Brobecker <brobecker@adacore.com> wrote:
>> >> AFAIR, there was a suggestion some time ago to remove TUI support
>> >> altogether.
>> >
>> > So the developers don't use it at all themselves?
>> 
>> I use TUI a lot, and I know other developers do as well.  I don't
>> remember the proposal to remove TUI, and recently we have been
>receiving
>> some nice patches to fix issues on it.
>
>I might have mentioned the idea a few years back, but it was
>very quickly dismissed ;-).

Please don't remove it. If you disabled everything that didn't work on windows, there would be no simulators either. Lol

--joel

Re: building gdb with TUI support on Windows

[Joel Brobecker]

> >I might have mentioned the idea a few years back, but it was
> >very quickly dismissed ;-).
> 
> Please don't remove it. If you disabled everything that didn't work on
> windows, there would be no simulators either. Lol

There is no risk of it being removed at the moment; but just to clarify,
the suggestion I made at the time was not related to support on Windows
(or lack of it) but to the perception that maybe people might not have
been using it (which turned out to be wrong). Hence the dismissing ;-).

-- 
Joel