Re: [PATCH v2 0/2] MI: Add new command -complete

Re: [PATCH v2 0/2] MI: Add new command -complete

[Jan Vrany]

On Wed, 2019-02-20 at 14:20 -0700, Tom Tromey wrote:
> > > > > > "Jan" == Jan Vrany <jan.vrany@fit.cvut.cz> writes:
> 
> Jan> respond with something like (proposed change):
> 
> Jan> -complete "br m"
> Jan> =^done,text="br m",common="a",matches=["in", "dvise"]
> 
> Jan> The rarionale is that frontend most likely needs these three
> Jan> values anyway to implement completion. It can, indeed compute
> Jan> them from full list as returned now, but GDB has these values
> Jan> already so it would save the frontend doing the same work again. 
> 
> Jan> OTOH, current output is more on par with CLI command output. 
> 
> Jan> What do you think? 
> 
> I think if this form seems more useful to MI users, then it's fine to
> implement it.  I would say this is more important than making it similar
> to the CLI.

Are there any other GDB/MI users to comment on this? What would you prefer?

Jan

Re: [PATCH v2 0/2] MI: Add new command -complete

[Tom Tromey]

>>>>> "Jan" == Jan Vrany <jan.vrany@fit.cvut.cz> writes:

Jan> Are there any other GDB/MI users to comment on this? What would you
Jan> prefer?

Given the lack of response, I think you should just say which you
prefer.  If you think it would be better the "other" way, go for it.
Or if you'd rather the patches you already have, let me know.

thanks,
Tom

Re: [PATCH v2 0/2] MI: Add new command -complete

[Jan Vrany]

On Tue, 2019-02-26 at 12:49 -0700, Tom Tromey wrote:
> > > > > > "Jan" == Jan Vrany <jan.vrany@fit.cvut.cz> writes:
> 
> Or if you'd rather the patches you already have, let me know.
> 

Yes, I would prefer to have it as implemented in v2 patch mini-series
Thanks!

Jan

Re: [PATCH v2 0/2] MI: Add new command -complete

[Pedro Alves]

I'm totally not against this new command at all, but I have to say that I'd be
much more thrilled if someone just spent the time to make separate CLI/MI
channels work on Windows too.  The channel doesn't _have_ to be a PTY.

On 02/26/2019 07:49 PM, Tom Tromey wrote:
>>>>>> "Jan" == Jan Vrany <jan.vrany@fit.cvut.cz> writes:
> 
> Jan> Are there any other GDB/MI users to comment on this? What would you
> Jan> prefer?
> 
> Given the lack of response, I think you should just say which you
> prefer.  If you think it would be better the "other" way, go for it.
> Or if you'd rather the patches you already have, let me know.

Jan, please consider the wildmatching case.  E.g., when debugging GDB itself:

(gdb) b push_bac<TAB>
Display all 102 possibilities? (y or n)
debug_names::offset_vec_tmpl<unsigned int>::push_back_reorder(unsigned long)
debug_names::offset_vec_tmpl<unsigned long>::push_back_reorder(unsigned long)
std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::push_back(char)
...

The frontend needs to complete "b push_bac" -> "b push_back", and present
the matches.

But the least common denominator is not at the start of the matches
strings.  How will a frontend compute the LCD from the matches list alone?

Please mind the "2018" copyright year in the testcase.

Thanks,
Pedro Alves

Re: [PATCH v2 0/2] MI: Add new command -complete

[Jan Vrany]

Hello,

On Wed, 2019-02-27 at 20:41 +0000, Pedro Alves wrote:
> I'm totally not against this new command at all, but I have to say that I'd be
> much more thrilled if someone just spent the time to make separate CLI/MI
> channels work on Windows too.  The channel doesn't _have_ to be a PTY.

I know. That was my initial idea just to use named pipes year or two back
when I started to support Windows. However:

1) Completion CLI is AFAIK implemented using readline which has problems 
   working over pipes. Actually, I never got CLI working satisfactorily
   on Windows even when I just run GDB "normally" from Windows command shell (`cmd.exe`),
   let alone over pipes or alike. 

2) Even if it would work, there are still other usecases which working readline
   and separate CLI/MI channel on Windows would not support. For example:
   
   (a) at the moment we use "my" frontend [1], [2] running on developers laptop 
       connecting over ssh to a GDB that runs on remote RISC-V machine. Essentially,
       instead of lauching gdb locally (on dev's machine) like: 

         gdb path/to/binary

       we do 

         ssh unleashed gdb -i=mi2 path/to/binary

       In this case, opening a secondary MI channel is very problematic. 
       -complete command gives me at least a way to implement completion which
       we found very important. There are still some quirks with that, sure, 
       like when you run `pi` or `shell` commands it completely ruins the MI 
       channel (this is a bug have not yet looked at let alone fixed but it is 
       on my very long list).

   (b) another frontend feature asked was to provide a kind of "workspace" for GDB commands,
       This is essentially a text editor in which you write ad-hoc commands (possibly
       with comments) and execute them by selecting portion of a text and pressing a button
       (or with a shortcut). -complete command would allow me to implement completion
       in such "workspace" 

       (I know, this may sound like a weird UI, but this is essentially what a Smalltalk workspace
       is but for GDB commands. So far users of this frontend are mainly - me including -  
       a small bunch of old smalltalkers working on virtual machines)

[1]: https://bitbucket.org/janvrany/jv-vdb/src/default/
[2]: https://bitbucket.org/janvrany/jv-libgdbs/src/default/
[3]: https://bitbucket.org/janvrany/jv-vdb/src/default/doc/Invoking.md
   
> 
> On 02/26/2019 07:49 PM, Tom Tromey wrote:
> > > > > > > "Jan" == Jan Vrany <jan.vrany@fit.cvut.cz> writes:
> > 
> > Jan> Are there any other GDB/MI users to comment on this? What would you
> > Jan> prefer?
> > 
> > Given the lack of response, I think you should just say which you
> > prefer.  If you think it would be better the "other" way, go for it.
> > Or if you'd rather the patches you already have, let me know.
> 
> Jan, please consider the wildmatching case.  E.g., when debugging GDB itself:
> 
> (gdb) b push_bac<TAB>
> Display all 102 possibilities? (y or n)
> debug_names::offset_vec_tmpl<unsigned int>::push_back_reorder(unsigned long)
> debug_names::offset_vec_tmpl<unsigned long>::push_back_reorder(unsigned long)
> std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::push_back(char)
> ...
> 
> The frontend needs to complete "b push_bac" -> "b push_back", and present
> the matches.
> 
> But the least common denominator is not at the start of the matches
> strings.  How will a frontend compute the LCD from the matches list alone?

I see. I was not aware of this behavior, thanks for pointing this out! I'll address that
in next iterations. 

Thanks a lot! 

Jan

Re: [PATCH v2 0/2] MI: Add new command -complete

[Pedro Alves]

On 02/28/2019 10:18 AM, Jan Vrany wrote:
> Hello,
> 
> On Wed, 2019-02-27 at 20:41 +0000, Pedro Alves wrote:
>> I'm totally not against this new command at all, but I have to say that I'd be
>> much more thrilled if someone just spent the time to make separate CLI/MI
>> channels work on Windows too.  The channel doesn't _have_ to be a PTY.
> 
> I know. That was my initial idea just to use named pipes year or two back
> when I started to support Windows. However:
> 
> 1) Completion CLI is AFAIK implemented using readline which has problems 
>    working over pipes. Actually, I never got CLI working satisfactorily
>    on Windows even when I just run GDB "normally" from Windows command shell (`cmd.exe`),
>    let alone over pipes or alike. 

Curious.  AFAIK native Windows gdb over cmd.exe should work fine.

Over pipes or the like, indeed I wouldn't be surprised with issues.
"set interactive-mode on" may help.

BTW, (and I just remembered that after sending the previous email), AFAIK,
Eclipse made the GDB console (with new-ui) work in the Windows port by
using WinPTY.

> 
> 2) Even if it would work, there are still other usecases which working readline
>    and separate CLI/MI channel on Windows would not support. For example:
>    
>    (a) at the moment we use "my" frontend [1], [2] running on developers laptop 
>        connecting over ssh to a GDB that runs on remote RISC-V machine. Essentially,
>        instead of lauching gdb locally (on dev's machine) like: 
> 
>          gdb path/to/binary
> 
>        we do 
> 
>          ssh unleashed gdb -i=mi2 path/to/binary
> 
>        In this case, opening a secondary MI channel is very problematic. 

Why's that problematic?  You could forward a tcp port or a unix domain socket
over shh for MI?  Again, there's no real reason that new-ui only works with
ptys, other than noone ever tweaking the code to support other file types.

>        -complete command gives me at least a way to implement completion which
>        we found very important. There are still some quirks with that, sure, 
>        like when you run `pi` or `shell` commands it completely ruins the MI 
>        channel (this is a bug have not yet looked at let alone fixed but it is 
>        on my very long list).
> 

To me, it seems like you'll never manage to mimic gdb's behavior perfectly.
new-ui gets you perfect behavior, because, well, there's no mimicing.

>    (b) another frontend feature asked was to provide a kind of "workspace" for GDB commands,
>        This is essentially a text editor in which you write ad-hoc commands (possibly
>        with comments) and execute them by selecting portion of a text and pressing a button
>        (or with a shortcut). -complete command would allow me to implement completion
>        in such "workspace" 
> 

I see.

>        (I know, this may sound like a weird UI, but this is essentially what a Smalltalk workspace
>        is but for GDB commands. So far users of this frontend are mainly - me including -  
>        a small bunch of old smalltalkers working on virtual machines)
> 
> [1]: https://bitbucket.org/janvrany/jv-vdb/src/default/
> [2]: https://bitbucket.org/janvrany/jv-libgdbs/src/default/
> [3]: https://bitbucket.org/janvrany/jv-vdb/src/default/doc/Invoking.md
>    
>>
>> On 02/26/2019 07:49 PM, Tom Tromey wrote:
>>>>>>>> "Jan" == Jan Vrany <jan.vrany@fit.cvut.cz> writes:
>>>
>>> Jan> Are there any other GDB/MI users to comment on this? What would you
>>> Jan> prefer?
>>>
>>> Given the lack of response, I think you should just say which you
>>> prefer.  If you think it would be better the "other" way, go for it.
>>> Or if you'd rather the patches you already have, let me know.
>>
>> Jan, please consider the wildmatching case.  E.g., when debugging GDB itself:
>>
>> (gdb) b push_bac<TAB>
>> Display all 102 possibilities? (y or n)
>> debug_names::offset_vec_tmpl<unsigned int>::push_back_reorder(unsigned long)
>> debug_names::offset_vec_tmpl<unsigned long>::push_back_reorder(unsigned long)
>> std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::push_back(char)
>> ...
>>
>> The frontend needs to complete "b push_bac" -> "b push_back", and present
>> the matches.
>>
>> But the least common denominator is not at the start of the matches
>> strings.  How will a frontend compute the LCD from the matches list alone?
> 
> I see. I was not aware of this behavior, thanks for pointing this out! I'll address that
> in next iterations. 

Another thing that I remembered is that in some cases, GDB's completion actually
replaces the whole complete word, instead of just appending.  For example, try:

  (gdb) handle sigv<TAB>

Results in:

  (gdb) handle SIGVTALRM

ISTR having run into other examples, but not recalling
them right now.

Thanks,
Pedro Alves

Re: [PATCH v2 0/2] MI: Add new command -complete

[Jan Vrany]

Hello, 

On Tue, 2019-03-05 at 20:53 +0000, Pedro Alves wrote:
> On 02/28/2019 10:18 AM, Jan Vrany wrote:
> > Hello,
> > 
> > On Wed, 2019-02-27 at 20:41 +0000, Pedro Alves wrote:
> > > I'm totally not against this new command at all, but I have to say that I'd be
> > > much more thrilled if someone just spent the time to make separate CLI/MI
> > > channels work on Windows too.  The channel doesn't _have_ to be a PTY.
> > 
> > I know. That was my initial idea just to use named pipes year or two back
> > when I started to support Windows. However:
> > 
> > 1) Completion CLI is AFAIK implemented using readline which has problems 
> >    working over pipes. Actually, I never got CLI working satisfactorily
> >    on Windows even when I just run GDB "normally" from Windows command shell (`cmd.exe`),
> >    let alone over pipes or alike. 
> 
> Curious.  AFAIK native Windows gdb over cmd.exe should work fine.

Maybe I just don't know how to compile it properly. I have just compiled
fresh c3734e093aab1ce from git (only with this patch 
https://sourceware.org/ml/gdb-patches/2018-10/msg00614.html to make it compile
with Python 3) using using MSYS2 MINGW64 toolchain on Windows 10. 
This is the exact configure command:

bash ../configure --build=x86_64-w64-mingw32 --disable-werror --with-guile=no --with-python=C:\msys64\mingw64\bin\python3 --enable-targets="i686-w64-mingw32,x86_64-w64-mingw32"

Completion by tab seem to work. 

Backspace practially does not, it deletes the character in the line 
buffer (presumably) but not on the screen. Instead, it moves the caret 
one character on the right. Therefore what use see on the screen is not 
what it sent to GDB when she presses enter. 

Moving cursor by left arrow followed by typing has similar issues. 
Same for delete. Same for pressing Ctrl-R for searching the history. 

Generally, internally the state of the buffer might be OK (hard to tell)
but what is shown on the screen is completely out of sync, making it really 
hard to work with, at least for me. 

Again, it might well be just that I don't know how to configure / compile 
things properly. In the past I tried pre-compiled GDBs from cygwin & msys2
various versions of each and each of them has similar issues so I give up
digging deeper. 


> 
> Over pipes or the like, indeed I wouldn't be surprised with issues.
> "set interactive-mode on" may help.
> 
> BTW, (and I just remembered that after sending the previous email), AFAIK,
> Eclipse made the GDB console (with new-ui) work in the Windows port by
> using WinPTY.

I was not aware of this. I'll have a look at eclipse code. Thanks!

> 
> > 2) Even if it would work, there are still other usecases which working readline
> >    and separate CLI/MI channel on Windows would not support. For example:
> >    
> >    (a) at the moment we use "my" frontend [1], [2] running on developers laptop 
> >        connecting over ssh to a GDB that runs on remote RISC-V machine. Essentially,
> >        instead of lauching gdb locally (on dev's machine) like: 
> > 
> >          gdb path/to/binary
> > 
> >        we do 
> > 
> >          ssh unleashed gdb -i=mi2 path/to/binary
> > 
> >        In this case, opening a secondary MI channel is very problematic. 
> 
> Why's that problematic?  You could forward a tcp port or a unix domain socket
> over shh for MI?  Again, there's no real reason that new-ui only works with
> ptys, other than noone ever tweaking the code to support other file types.
> 

This could be a way, yes. I just find it little too fiddly to implement. 
Using ssh command has some problems, using things like libssh has other problems.
Little details, but that's where the devil is. Plus it does not solve the
issues on Windows I described above nor the would it help me with the workspace.
So it seems to me that -complete would be a reasonable way to deal with all that. 

> >        -complete command gives me at least a way to implement completion which
> >        we found very important. There are still some quirks with that, sure, 
> >        like when you run `pi` or `shell` commands it completely ruins the MI 
> >        channel (this is a bug have not yet looked at let alone fixed but it is 
> >        on my very long list).
> > 
> 
> To me, it seems like you'll never manage to mimic gdb's behavior perfectly.
> new-ui gets you perfect behavior, because, well, there's no mimicing.
> 

Well, I'm not seeking to have perfect imitation of gdb's behavior. Just good enough. 

> >    (b) another frontend feature asked was to provide a kind of "workspace" for GDB commands,
> >        This is essentially a text editor in which you write ad-hoc commands (possibly
> >        with comments) and execute them by selecting portion of a text and pressing a button
> >        (or with a shortcut). -complete command would allow me to implement completion
> >        in such "workspace" 
> > 
> 
> I see.
> 
> >        (I know, this may sound like a weird UI, but this is essentially what a Smalltalk workspace
> >        is but for GDB commands. So far users of this frontend are mainly - me including -  
> >        a small bunch of old smalltalkers working on virtual machines)
> > 
> > [1]: https://bitbucket.org/janvrany/jv-vdb/src/default/
> > [2]: https://bitbucket.org/janvrany/jv-libgdbs/src/default/
> > [3]: https://bitbucket.org/janvrany/jv-vdb/src/default/doc/Invoking.md
> >    
> > > On 02/26/2019 07:49 PM, Tom Tromey wrote:
> > > > > > > > > "Jan" == Jan Vrany <jan.vrany@fit.cvut.cz> writes:
> > > > 
> > > > Jan> Are there any other GDB/MI users to comment on this? What would you
> > > > Jan> prefer?
> > > > 
> > > > Given the lack of response, I think you should just say which you
> > > > prefer.  If you think it would be better the "other" way, go for it.
> > > > Or if you'd rather the patches you already have, let me know.
> > > 
> > > Jan, please consider the wildmatching case.  E.g., when debugging GDB itself:
> > > 
> > > (gdb) b push_bac<TAB>
> > > Display all 102 possibilities? (y or n)
> > > debug_names::offset_vec_tmpl<unsigned int>::push_back_reorder(unsigned long)
> > > debug_names::offset_vec_tmpl<unsigned long>::push_back_reorder(unsigned long)
> > > std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::push_back(char)
> > > ...
> > > 
> > > The frontend needs to complete "b push_bac" -> "b push_back", and present
> > > the matches.
> > > 
> > > But the least common denominator is not at the start of the matches
> > > strings.  How will a frontend compute the LCD from the matches list alone?
> > 
> > I see. I was not aware of this behavior, thanks for pointing this out! I'll address that
> > in next iterations. 
> 
> Another thing that I remembered is that in some cases, GDB's completion actually
> replaces the whole complete word, instead of just appending.  For example, try:
> 
>   (gdb) handle sigv<TAB>
> 
> Results in:
> 
>   (gdb) handle SIGVTALRM
> 
> ISTR having run into other examples, but not recalling
> them right now.

I think this is handled by v3:

(gdb) 
-complete "handle sigv"
^done,completion="handle SIGVTALRM",matches=["handle SIGVTALRM"],max_completions_reached="0"
(gdb) 


Anyways, another way to look at this commit is that there's already 
CLI command "complete" and this commit "merely" add an MI counterpart of it,
exposing over MI what's already available in CLI. 

If the maintenance cost -complete is considered "too much for little gain", let's 
drop it.  

Thanks! 

Jan

> 
> Thanks,
> Pedro Alves

Re: [PATCH v2 0/2] MI: Add new command -complete

[Eli Zaretskii]

> From: Jan Vrany <jan.vrany@fit.cvut.cz>
> Cc: gdb-patches@sourceware.org, "gdb@sourceware.org" <gdb@sourceware.org>
> Date: Wed, 06 Mar 2019 15:09:33 +0000
> 
> > > 1) Completion CLI is AFAIK implemented using readline which has problems 
> > >    working over pipes. Actually, I never got CLI working satisfactorily
> > >    on Windows even when I just run GDB "normally" from Windows command shell (`cmd.exe`),
> > >    let alone over pipes or alike. 
> > 
> > Curious.  AFAIK native Windows gdb over cmd.exe should work fine.
> 
> Maybe I just don't know how to compile it properly. I have just compiled
> fresh c3734e093aab1ce from git (only with this patch 
> https://sourceware.org/ml/gdb-patches/2018-10/msg00614.html to make it compile
> with Python 3) using using MSYS2 MINGW64 toolchain on Windows 10. 
> This is the exact configure command:
> 
> bash ../configure --build=x86_64-w64-mingw32 --disable-werror --with-guile=no --with-python=C:\msys64\mingw64\bin\python3 --enable-targets="i686-w64-mingw32,x86_64-w64-mingw32"
> 
> Completion by tab seem to work. 
> 
> Backspace practially does not, it deletes the character in the line 
> buffer (presumably) but not on the screen. Instead, it moves the caret 
> one character on the right. Therefore what use see on the screen is not 
> what it sent to GDB when she presses enter. 
> 
> Moving cursor by left arrow followed by typing has similar issues. 
> Same for delete. Same for pressing Ctrl-R for searching the history. 

How did you invoke GDB from cmd.exe, to make these problems appear?
Can you show your exact invocation command line?

Re: [PATCH v2 0/2] MI: Add new command -complete

[Jan Vrany]

On Wed, 2019-03-06 at 17:45 +0200, Eli Zaretskii wrote:
> > From: Jan Vrany <jan.vrany@fit.cvut.cz>
> > Cc: gdb-patches@sourceware.org, "gdb@sourceware.org" <gdb@sourceware.org>
> > Date: Wed, 06 Mar 2019 15:09:33 +0000
> > 
> > > > 1) Completion CLI is AFAIK implemented using readline which has problems 
> > > >    working over pipes. Actually, I never got CLI working satisfactorily
> > > >    on Windows even when I just run GDB "normally" from Windows command shell (`cmd.exe`),
> > > >    let alone over pipes or alike. 
> > > 
> > > Curious.  AFAIK native Windows gdb over cmd.exe should work fine.
> > 
> > Maybe I just don't know how to compile it properly. I have just compiled
> > fresh c3734e093aab1ce from git (only with this patch 
> > https://sourceware.org/ml/gdb-patches/2018-10/msg00614.html to make it compile
> > with Python 3) using using MSYS2 MINGW64 toolchain on Windows 10. 
> > This is the exact configure command:
> > 
> > bash ../configure --build=x86_64-w64-mingw32 --disable-werror --with-guile=no --with-python=C:\msys64\mingw64\bin\python3 --enable-targets="i686-w64-mingw32,x86_64-w64-mingw32"
> > 
> > Completion by tab seem to work. 
> > 
> > Backspace practially does not, it deletes the character in the line 
> > buffer (presumably) but not on the screen. Instead, it moves the caret 
> > one character on the right. Therefore what use see on the screen is not 
> > what it sent to GDB when she presses enter. 
> > 
> > Moving cursor by left arrow followed by typing has similar issues. 
> > Same for delete. Same for pressing Ctrl-R for searching the history. 
> 
> How did you invoke GDB from cmd.exe, to make these problems appear?
> Can you show your exact invocation command line?

Just like:

H:\Projects\gdb\master\build-x86_64-msys2\gdb>gdb.exe

HTH, 

Jan

Re: [PATCH v2 0/2] MI: Add new command -complete

[Eli Zaretskii]

> From: Jan Vrany <jan.vrany@fit.cvut.cz>
> Cc: palves@redhat.com, tom@tromey.com, gdb-patches@sourceware.org,
>         gdb@sourceware.org
> Date: Wed, 06 Mar 2019 16:36:39 +0000
> 
> > > Completion by tab seem to work. 
> > > 
> > > Backspace practially does not, it deletes the character in the line 
> > > buffer (presumably) but not on the screen. Instead, it moves the caret 
> > > one character on the right. Therefore what use see on the screen is not 
> > > what it sent to GDB when she presses enter. 
> > > 
> > > Moving cursor by left arrow followed by typing has similar issues. 
> > > Same for delete. Same for pressing Ctrl-R for searching the history. 
> > 
> > How did you invoke GDB from cmd.exe, to make these problems appear?
> > Can you show your exact invocation command line?
> 
> Just like:
> 
> H:\Projects\gdb\master\build-x86_64-msys2\gdb>gdb.exe

But this doesn't create any pipes to communicate with GDB.  Instead,
this communicates via the default stdin/stdout connected to the
console, and GDB should recognize it as such.  So all the problems you
describe should not happen, and indeed don't happen for me when I
invoke GDB from cmd.exe.

Do you perhaps have a ~/.inputrc file, or some other local
customization, which might affect how Readline works?  because what
you describe surely sounds like broken Readline.

Readline on Windows (WAS: Re: [PATCH v2 0/2] MI: Add new command -complete]

[Jan Vrany]

Hi, 

I changed the subject as we got quite far from the original
topic.

> > > 
> > > How did you invoke GDB from cmd.exe, to make these problems appear?
> > > Can you show your exact invocation command line?
> > 
> > Just like:
> > 
> > H:\Projects\gdb\master\build-x86_64-msys2\gdb>gdb.exe
> 
> But this doesn't create any pipes to communicate with GDB.  Instead,
> this communicates via the default stdin/stdout connected to the
> console, and GDB should recognize it as such.  So all the problems you
> describe should not happen, and indeed don't happen for me when I
> invoke GDB from cmd.exe.

Ah, sorry, I should have been more clear. I meant that it does not work
for me EVEN when on standard console so I doubted it would work better over 
pipes much better.

All the problems I described do happen when using standard console and never
worked no matter which GDB I used (compiled by myself or by some third party).

> 
> Do you perhaps have a ~/.inputrc file, or some other local
> customization, which might affect how Readline works? 

Not that I know of. There's no ".inputrc" nor "inputrc" on my Windows filesystem.
I believe GDB compiled by myself uses the readline that comes with GDB.

Thanks!

Re: Readline on Windows (WAS: Re: [PATCH v2 0/2] MI: Add new command -complete]

[Eli Zaretskii]

> From: Jan Vrany <jan.vrany@fit.cvut.cz>
> Cc: palves@redhat.com, tom@tromey.com, gdb@sourceware.org
> Date: Mon, 11 Mar 2019 08:45:55 +0000
> 
> Ah, sorry, I should have been more clear. I meant that it does not work
> for me EVEN when on standard console so I doubted it would work better over 
> pipes much better.
> 
> All the problems I described do happen when using standard console and never
> worked no matter which GDB I used (compiled by myself or by some third party).

That's strange.  Do you have some curses library installed, and if so,
does it get linked into GDB?

> > Do you perhaps have a ~/.inputrc file, or some other local
> > customization, which might affect how Readline works? 
> 
> Not that I know of. There's no ".inputrc" nor "inputrc" on my Windows filesystem.
> I believe GDB compiled by myself uses the readline that comes with GDB.

The .inputrc file doesn't come with Readline, it is a user init file
that you yourself can create to customize how input through readline
works.

I compile GDB myself as well, also with its bundled readline, I use
GDB in the Windows console all the time, and I have no problems like
the ones you describe.  Very strange.

Re: Readline on Windows (WAS: Re: [PATCH v2 0/2] MI: Add new command -complete]

[Jan Vrany]

On Mon, 2019-03-11 at 16:43 +0200, Eli Zaretskii wrote:
> > From: Jan Vrany <jan.vrany@fit.cvut.cz>
> > Cc: palves@redhat.com, tom@tromey.com, gdb@sourceware.org
> > Date: Mon, 11 Mar 2019 08:45:55 +0000
> > 
> > Ah, sorry, I should have been more clear. I meant that it does not work
> > for me EVEN when on standard console so I doubted it would work better over 
> > pipes much better.
> > 
> > All the problems I described do happen when using standard console and never
> > worked no matter which GDB I used (compiled by myself or by some third party).
> 
> That's strange.  Do you have some curses library installed, and if so,
> does it get linked into GDB?

No, this is the output of ldd:

      ntdll.dll => /c/WINDOWS/SYSTEM32/ntdll.dll (0x7fffba1c0000)
        KERNEL32.DLL => /c/WINDOWS/System32/KERNEL32.DLL (0x7fffb9520000)
        KERNELBASE.dll => /c/WINDOWS/System32/KERNELBASE.dll (0x7fffb6630000)
        msvcrt.dll => /c/WINDOWS/System32/msvcrt.dll (0x7fffb9770000)
        USER32.dll => /c/WINDOWS/System32/USER32.dll (0x7fffb95e0000)
        win32u.dll => /c/WINDOWS/System32/win32u.dll (0x7fffb7520000)
        GDI32.dll => /c/WINDOWS/System32/GDI32.dll (0x7fffb7d70000)
        gdi32full.dll => /c/WINDOWS/System32/gdi32full.dll (0x7fffb7280000)
        msvcp_win.dll => /c/WINDOWS/System32/msvcp_win.dll (0x7fffb6590000)
        ucrtbase.dll => /c/WINDOWS/System32/ucrtbase.dll (0x7fffb7420000)
        WS2_32.dll => /c/WINDOWS/System32/WS2_32.dll (0x7fffb9a50000)
        RPCRT4.dll => /c/WINDOWS/System32/RPCRT4.dll (0x7fffb77e0000)
        libgmp-10.dll => /mingw64/bin/libgmp-10.dll (0x6acc0000)
        libiconv-2.dll => /mingw64/bin/libiconv-2.dll (0x66000000)
        libintl-8.dll => /mingw64/bin/libintl-8.dll (0x61cc0000)
        ADVAPI32.dll => /c/WINDOWS/System32/ADVAPI32.dll (0x7fffb7e70000)
        sechost.dll => /c/WINDOWS/System32/sechost.dll (0x7fffb9460000)
        libexpat-1.dll => /mingw64/bin/libexpat-1.dll (0x68f40000)
        liblzma-5.dll => /mingw64/bin/liblzma-5.dll (0x63cc0000)
        libpython3.7m.dll => /mingw64/bin/libpython3.7m.dll (0x62300000)
        libwinpthread-1.dll => /mingw64/bin/libwinpthread-1.dll (0x64940000)
        VERSION.dll => /c/WINDOWS/SYSTEM32/VERSION.dll (0x7fffa9ac0000)
> 

> > > Do you perhaps have a ~/.inputrc file, or some other local
> > > customization, which might affect how Readline works? 
> > 
> > Not that I know of. There's no ".inputrc" nor "inputrc" on my Windows filesystem.
> > I believe GDB compiled by myself uses the readline that comes with GDB.
> 
> The .inputrc file doesn't come with Readline, it is a user init file
> that you yourself can create to customize how input through readline
> works.

I know. I just double checked that there is none accidentally created.

> 
> I compile GDB myself as well, also with its bundled readline, I use
> GDB in the Windows console all the time, and I have no problems like
> the ones you describe.  Very strange.

Strange indeed - but it is also good because this means that it "can". 

So I dug deeper and found --with-system-readline option (funny enough
configure --help does not mention it) and voila, with this config
it works well. This is ldd from "good" GDB: 

ntdll.dll => /c/WINDOWS/SYSTEM32/ntdll.dll (0x7fffba1c0000)
        KERNEL32.DLL => /c/WINDOWS/System32/KERNEL32.DLL (0x7fffb9520000)
        KERNELBASE.dll => /c/WINDOWS/System32/KERNELBASE.dll (0x7fffb6630000)
        msvcrt.dll => /c/WINDOWS/System32/msvcrt.dll (0x7fffb9770000)
        USER32.dll => /c/WINDOWS/System32/USER32.dll (0x7fffb95e0000)
        win32u.dll => /c/WINDOWS/System32/win32u.dll (0x7fffb7520000)
        GDI32.dll => /c/WINDOWS/System32/GDI32.dll (0x7fffb7d70000)
        gdi32full.dll => /c/WINDOWS/System32/gdi32full.dll (0x7fffb7280000)
        msvcp_win.dll => /c/WINDOWS/System32/msvcp_win.dll (0x7fffb6590000)
        ucrtbase.dll => /c/WINDOWS/System32/ucrtbase.dll (0x7fffb7420000)
        WS2_32.dll => /c/WINDOWS/System32/WS2_32.dll (0x7fffb9a50000)
        RPCRT4.dll => /c/WINDOWS/System32/RPCRT4.dll (0x7fffb77e0000)
        libgmp-10.dll => /mingw64/bin/libgmp-10.dll (0x6acc0000)
        libexpat-1.dll => /mingw64/bin/libexpat-1.dll (0x68f40000)
        libiconv-2.dll => /mingw64/bin/libiconv-2.dll (0x66000000)
        libintl-8.dll => /mingw64/bin/libintl-8.dll (0x61cc0000)
        ADVAPI32.dll => /c/WINDOWS/System32/ADVAPI32.dll (0x7fffb7e70000)
        sechost.dll => /c/WINDOWS/System32/sechost.dll (0x7fffb9460000)
        liblzma-5.dll => /mingw64/bin/liblzma-5.dll (0x63cc0000)
        libreadline7.dll => /mingw64/bin/libreadline7.dll (0x6e780000)
        libwinpthread-1.dll => /mingw64/bin/libwinpthread-1.dll (0x64940000)
        libpython3.7m.dll => /mingw64/bin/libpython3.7m.dll (0x62300000)
        VERSION.dll => /c/WINDOWS/SYSTEM32/VERSION.dll (0x7fffa9ac0000)
        libtermcap-0.dll => /mingw64/bin/libtermcap-0.dll (0x6ac40000)

One problem less. Not that it explains why bundled readline
does not work for me and does for you, but at least I can produce more usable 
gdb on Windows. Thanks a lot! 

Jan