This is the mail archive of the
mailing list for the GDB project.
Re: [PATCH v2 0/2] MI: Add new command -complete
- From: Pedro Alves <palves at redhat dot com>
- To: Jan Vrany <jan dot vrany at fit dot cvut dot cz>, Tom Tromey <tom at tromey dot com>
- Cc: gdb-patches at sourceware dot org, "gdb at sourceware dot org" <gdb at sourceware dot org>
- Date: Tue, 5 Mar 2019 20:53:52 +0000
- Subject: Re: [PATCH v2 0/2] MI: Add new command -complete
- References: <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org>
On 02/28/2019 10:18 AM, Jan Vrany wrote:
> 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
> 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 ,  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 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)
> : https://bitbucket.org/janvrany/jv-vdb/src/default/
> : https://bitbucket.org/janvrany/jv-libgdbs/src/default/
> : https://bitbucket.org/janvrany/jv-vdb/src/default/doc/Invoking.md
>> On 02/26/2019 07:49 PM, Tom Tromey wrote:
>>>>>>>> "Jan" == Jan Vrany <email@example.com> 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>
(gdb) handle SIGVTALRM
ISTR having run into other examples, but not recalling
them right now.