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

[Jan Vrany <jan dot vrany at fit dot cvut dot cz>]

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