From: Pedro Alves <palves@redhat.com>
To: Jan Vrany <jan.vrany@fit.cvut.cz>, Tom Tromey <tom@tromey.com>
Cc: gdb-patches@sourceware.org, "gdb@sourceware.org" <gdb@sourceware.org>
Subject: Re: [PATCH v2 0/2] MI: Add new command -complete
Date: Tue, 05 Mar 2019 20:53:00 -0000 [thread overview]
Message-ID: <b4f7d9f8-3b11-0050-8be0-1388cf37b113@redhat.com> (raw)
In-Reply-To: <08b77764c3236cf652d981b3df1e78c185f6673e.camel@fit.cvut.cz>
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
next prev parent reply other threads:[~2019-03-05 20:53 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <87imynm3ia.fsf@tromey.com>
[not found] ` <20190128124101.26243-1-jan.vrany@fit.cvut.cz>
[not found] ` <87pnrmnolt.fsf@tromey.com>
2019-02-21 16:05 ` Jan Vrany
2019-02-26 19:49 ` Tom Tromey
2019-02-27 10:41 ` Jan Vrany
2019-02-27 20:41 ` Pedro Alves
2019-02-28 10:18 ` Jan Vrany
2019-03-05 20:53 ` Pedro Alves [this message]
2019-03-06 15:09 ` Jan Vrany
2019-03-06 15:45 ` Eli Zaretskii
2019-03-06 16:37 ` Jan Vrany
2019-03-06 17:36 ` Eli Zaretskii
2019-03-11 8:46 ` Readline on Windows (WAS: Re: [PATCH v2 0/2] MI: Add new command -complete] Jan Vrany
2019-03-11 14:43 ` Eli Zaretskii
2019-03-12 11:43 ` Jan Vrany
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b4f7d9f8-3b11-0050-8be0-1388cf37b113@redhat.com \
--to=palves@redhat.com \
--cc=gdb-patches@sourceware.org \
--cc=gdb@sourceware.org \
--cc=jan.vrany@fit.cvut.cz \
--cc=tom@tromey.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).