From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 36898 invoked by alias); 5 Mar 2019 20:53:59 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 36869 invoked by uid 89); 5 Mar 2019 20:53:59 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 spammy=connecting, tab, possibilities, wildmatching X-HELO: mail-wm1-f66.google.com Received: from mail-wm1-f66.google.com (HELO mail-wm1-f66.google.com) (209.85.128.66) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 05 Mar 2019 20:53:57 +0000 Received: by mail-wm1-f66.google.com with SMTP id y15so3916258wma.0 for ; Tue, 05 Mar 2019 12:53:57 -0800 (PST) Return-Path: Received: from ?IPv6:2001:8a0:f913:f700:4c97:6d52:2cea:997b? ([2001:8a0:f913:f700:4c97:6d52:2cea:997b]) by smtp.gmail.com with ESMTPSA id q135sm434402wme.43.2019.03.05.12.53.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 05 Mar 2019 12:53:54 -0800 (PST) Subject: Re: [PATCH v2 0/2] MI: Add new command -complete To: Jan Vrany , Tom Tromey 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> <08b77764c3236cf652d981b3df1e78c185f6673e.camel@fit.cvut.cz> Cc: gdb-patches@sourceware.org, "gdb@sourceware.org" From: Pedro Alves Message-ID: Date: Tue, 05 Mar 2019 20:53:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <08b77764c3236cf652d981b3df1e78c185f6673e.camel@fit.cvut.cz> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2019-03/txt/msg00073.txt.bz2 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 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. 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 Results in: (gdb) handle SIGVTALRM ISTR having run into other examples, but not recalling them right now. Thanks, Pedro Alves