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

Pedro Alves
2019-03-05T20:53:59Z

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