[PATCH v2 0/2] MI: Add new command -complete
Jan Vrany
jan.vrany@fit.cvut.cz
Thu Feb 28 10:18:00 GMT 2019
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
More information about the Gdb-patches
mailing list