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

Message ID 20190128124101.26243-1-jan.vrany@fit.cvut.cz
Headers show
Series
  • MI: Add new command -complete
Related show

Message

Jan Vrany Jan. 28, 2019, 12:40 p.m.
This is a rework of previous patch based on Tom's comments.

Another thing worth considering (not done in this version) is to
have more structured result. Instead of (current version):

-complete "br m"
=^done,completions=["br main", "br madvise"]

respond with something like (proposed change):

-complete "br m"
=^done,text="br m",common="a",matches=["in", "dvise"]

The rarionale is that frontend most likely needs these three
values anyway to implement completion. It can, indeed compute
them from full list as returned now, but GDB has these values
already so it would save the frontend doing the same work again. 

OTOH, current output is more on par with CLI command output. 

What do you think? 

Differences v1 -> v2: 

  * extracted common completion logic to a new helper function
  * implemented MI command using a new mi-specific function rather
    than using CLI implementation.


Jan Vrany (2):
  MI: extract command completion logic from complete_command()
  MI: Add new command -complete

 gdb/ChangeLog                        | 14 ++++++
 gdb/NEWS                             |  7 +++
 gdb/cli/cli-cmds.c                   | 32 +------------
 gdb/completer.c                      | 34 +++++++++++++
 gdb/completer.h                      |  8 ++++
 gdb/doc/ChangeLog                    |  5 ++
 gdb/doc/gdb.texinfo                  | 31 ++++++++++++
 gdb/mi/mi-cmds.c                     |  2 +
 gdb/mi/mi-cmds.h                     |  1 +
 gdb/mi/mi-main.c                     | 44 +++++++++++++++++
 gdb/testsuite/ChangeLog              |  4 ++
 gdb/testsuite/gdb.mi/mi-complete.exp | 71 ++++++++++++++++++++++++++++
 12 files changed, 223 insertions(+), 30 deletions(-)
 create mode 100644 gdb/testsuite/gdb.mi/mi-complete.exp

-- 
2.20.1

Comments

Jan Vrany Feb. 13, 2019, 9:24 a.m. | #1
Polite ping. 

Jan

On Mon, 2019-02-04 at 10:00 +0000, Jan Vrany wrote:
> Polite ping. 

> 

> Jan

> 

> On Mon, 2019-01-28 at 12:40 +0000, Jan Vrany wrote:

> > This is a rework of previous patch based on Tom's comments.

> > 

> > Another thing worth considering (not done in this version) is to

> > have more structured result. Instead of (current version):

> > 

> > -complete "br m"

> > =^done,completions=["br main", "br madvise"]

> > 

> > respond with something like (proposed change):

> > 

> > -complete "br m"

> > =^done,text="br m",common="a",matches=["in", "dvise"]

> > 

> > The rarionale is that frontend most likely needs these three

> > values anyway to implement completion. It can, indeed compute

> > them from full list as returned now, but GDB has these values

> > already so it would save the frontend doing the same work again. 

> > 

> > OTOH, current output is more on par with CLI command output. 

> > 

> > What do you think? 

> > 

> > Differences v1 -> v2: 

> > 

> >   * extracted common completion logic to a new helper function

> >   * implemented MI command using a new mi-specific function rather

> >     than using CLI implementation.

> > 

> > 

> > Jan Vrany (2):

> >   MI: extract command completion logic from complete_command()

> >   MI: Add new command -complete

> > 

> >  gdb/ChangeLog                        | 14 ++++++

> >  gdb/NEWS                             |  7 +++

> >  gdb/cli/cli-cmds.c                   | 32 +------------

> >  gdb/completer.c                      | 34 +++++++++++++

> >  gdb/completer.h                      |  8 ++++

> >  gdb/doc/ChangeLog                    |  5 ++

> >  gdb/doc/gdb.texinfo                  | 31 ++++++++++++

> >  gdb/mi/mi-cmds.c                     |  2 +

> >  gdb/mi/mi-cmds.h                     |  1 +

> >  gdb/mi/mi-main.c                     | 44 +++++++++++++++++

> >  gdb/testsuite/ChangeLog              |  4 ++

> >  gdb/testsuite/gdb.mi/mi-complete.exp | 71 ++++++++++++++++++++++++++++

> >  12 files changed, 223 insertions(+), 30 deletions(-)

> >  create mode 100644 gdb/testsuite/gdb.mi/mi-complete.exp

> >
Jan Vrany Feb. 19, 2019, 7:33 a.m. | #2
Polite ping. 

Jan

On Wed, 2019-02-13 at 09:24 +0000, Jan Vrany wrote:
> Polite ping. 

> 

> Jan

> 

> On Mon, 2019-02-04 at 10:00 +0000, Jan Vrany wrote:

> > Polite ping. 

> > 

> > Jan

> > 

> > On Mon, 2019-01-28 at 12:40 +0000, Jan Vrany wrote:

> > > This is a rework of previous patch based on Tom's comments.

> > > 

> > > Another thing worth considering (not done in this version) is to

> > > have more structured result. Instead of (current version):

> > > 

> > > -complete "br m"

> > > =^done,completions=["br main", "br madvise"]

> > > 

> > > respond with something like (proposed change):

> > > 

> > > -complete "br m"

> > > =^done,text="br m",common="a",matches=["in", "dvise"]

> > > 

> > > The rarionale is that frontend most likely needs these three

> > > values anyway to implement completion. It can, indeed compute

> > > them from full list as returned now, but GDB has these values

> > > already so it would save the frontend doing the same work again. 

> > > 

> > > OTOH, current output is more on par with CLI command output. 

> > > 

> > > What do you think? 

> > > 

> > > Differences v1 -> v2: 

> > > 

> > >   * extracted common completion logic to a new helper function

> > >   * implemented MI command using a new mi-specific function rather

> > >     than using CLI implementation.

> > > 

> > > 

> > > Jan Vrany (2):

> > >   MI: extract command completion logic from complete_command()

> > >   MI: Add new command -complete

> > > 

> > >  gdb/ChangeLog                        | 14 ++++++

> > >  gdb/NEWS                             |  7 +++

> > >  gdb/cli/cli-cmds.c                   | 32 +------------

> > >  gdb/completer.c                      | 34 +++++++++++++

> > >  gdb/completer.h                      |  8 ++++

> > >  gdb/doc/ChangeLog                    |  5 ++

> > >  gdb/doc/gdb.texinfo                  | 31 ++++++++++++

> > >  gdb/mi/mi-cmds.c                     |  2 +

> > >  gdb/mi/mi-cmds.h                     |  1 +

> > >  gdb/mi/mi-main.c                     | 44 +++++++++++++++++

> > >  gdb/testsuite/ChangeLog              |  4 ++

> > >  gdb/testsuite/gdb.mi/mi-complete.exp | 71 ++++++++++++++++++++++++++++

> > >  12 files changed, 223 insertions(+), 30 deletions(-)

> > >  create mode 100644 gdb/testsuite/gdb.mi/mi-complete.exp

> > >
Tom Tromey Feb. 20, 2019, 9:20 p.m. | #3
>>>>> "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.

Tom
Jan Vrany Feb. 21, 2019, 4:05 p.m. | #4
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
Tom Tromey Feb. 26, 2019, 7:49 p.m. | #5
>>>>> "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
Jan Vrany Feb. 27, 2019, 10:41 a.m. | #6
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
Pedro Alves Feb. 27, 2019, 8:41 p.m. | #7
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
Jan Vrany Feb. 28, 2019, 10:18 a.m. | #8
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
Pedro Alves March 5, 2019, 8:53 p.m. | #9
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
Jan Vrany March 6, 2019, 3:09 p.m. | #10
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
Eli Zaretskii March 6, 2019, 3:45 p.m. | #11
> 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?
Jan Vrany March 6, 2019, 4:36 p.m. | #12
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
Eli Zaretskii March 6, 2019, 5:06 p.m. | #13
> 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.