From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 81163 invoked by alias); 28 Feb 2019 10:18:19 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 81140 invoked by uid 89); 28 Feb 2019 10:18:18 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_PASS autolearn=ham version=3.3.2 spammy=out!, ruins, H*r:may, H*r:forged X-HELO: relay.fit.cvut.cz Received: from relay.fit.cvut.cz (HELO relay.fit.cvut.cz) (147.32.232.237) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 28 Feb 2019 10:18:16 +0000 Received: from imap.fit.cvut.cz (imap.fit.cvut.cz [147.32.232.238]) by relay.fit.cvut.cz (8.15.2/8.15.2) with ESMTPS id x1SAI6lj078901 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 28 Feb 2019 11:18:08 +0100 (CET) (envelope-from jan.vrany@fit.cvut.cz) Received: from sao (5ac689c9.bb.sky.com [90.198.137.201] (may be forged)) (authenticated bits=0 as user vranyj1) by imap.fit.cvut.cz (8.15.2/8.15.2) with ESMTPSA id x1SAI3gw025957 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Thu, 28 Feb 2019 11:18:03 +0100 (CET) (envelope-from jan.vrany@fit.cvut.cz) Message-ID: <08b77764c3236cf652d981b3df1e78c185f6673e.camel@fit.cvut.cz> Subject: Re: [PATCH v2 0/2] MI: Add new command -complete From: Jan Vrany To: Pedro Alves , Tom Tromey Cc: gdb-patches@sourceware.org, "gdb@sourceware.org" Date: Thu, 28 Feb 2019 10:18:00 -0000 In-Reply-To: References: <87imynm3ia.fsf@tromey.com> <20190128124101.26243-1-jan.vrany@fit.cvut.cz> <87pnrmnolt.fsf@tromey.com> <6de282dee73cb44ae2016cb31254aa35c04e9816.camel@fit.cvut.cz> <87mumie3e2.fsf@tromey.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.30.5-1 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2019-02/txt/msg00082.txt.bz2 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 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 > Display all 102 possibilities? (y or n) > debug_names::offset_vec_tmpl::push_back_reorder(unsigned long) > debug_names::offset_vec_tmpl::push_back_reorder(unsigned long) > std::__cxx11::basic_string, std::allocator >::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