From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27940 invoked by alias); 17 Aug 2018 17:51:01 -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 27887 invoked by uid 89); 17 Aug 2018 17:50:57 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-6.9 required=5.0 tests=BAYES_00,GIT_PATCH_1,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=omissions, encourage, socalled, so-called X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 17 Aug 2018 17:50:55 +0000 Received: from smtp.corp.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 956B6308A95E; Fri, 17 Aug 2018 17:50:54 +0000 (UTC) Received: from theo.uglyboxes.com (ovpn04.gateway.prod.ext.phx2.redhat.com [10.5.9.4]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 4E18C98898; Fri, 17 Aug 2018 17:50:54 +0000 (UTC) Subject: Re: [PATCH 9/9] C++ compile support To: Eli Zaretskii Cc: gdb-patches@sourceware.org References: <20180810232534.481-1-keiths@redhat.com> <20180810232534.481-10-keiths@redhat.com> <83in4hmkpt.fsf@gnu.org> From: Keith Seitz Message-ID: Date: Fri, 17 Aug 2018 17:51:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <83in4hmkpt.fsf@gnu.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2018-08/txt/msg00426.txt.bz2 On 08/11/2018 12:22 AM, Eli Zaretskii wrote: >> From: Keith Seitz >> Date: Fri, 10 Aug 2018 16:25:34 -0700 >> >> This initial support has several glaring omissions: >> - No template support at all >> I have follow-on patches for this, but they add much complexity >> to this "basic" support. Consequently, they will be submitted separately. >> - Cannot print functions >> The code template needs tweaking, and I simply haven't gotten to it yet. >> - So-called "special function" support is not included >> Using constructors, destructors, operators, etc will not work. I have >> follow-on patches for that, but they require some work because of the >> recent churn in symbol searching. >> - There are several test suite references to "compile/1234" bugs. >> I will file bugs and update the test suite's bug references before pushing >> these patches. > > Shouldn't these omissions be mentioned somewhere? Like in NEWS? To be honest, I was hesitant to even mention this in NEWS at all (yet). The code is *very* beta and incomplete (as you can see). That's why the "experimental" moniker. Nonetheless, assuming we want to mention it, I've changed the entry to: * GDB now has experimental support for the compilation and injection of C++ source code into the inferior. This beta release does not include support for several language features, such as templates, constructors, and operators. > >> +* GDB now has experimental support for the compilation and injection of >> + C++ source code into the inferior. This feature requires the GCC C++ >> + plug-in available since GCC 7.1. > > The last sentence basically means "only on ELF platforms", right? So > IMO this limitation should be stated explicitly, lest people get > excited, and then get disappointed. I'm not sure how to answer this. That seems like enumerating all the dependencies of every dependency GDB has (bfd, libiberty, bison, etc). The feature (like the C compile feature already included) requires the compiler plug-in. Whatever that plug-in supports is what GDB supports. Would you like me to include something like: "Currently tested on x86_64 GNU/Linux." That tells readers what is known to work without suggesting all possible permutations of host/OS that might work [but are untested AFAIK]. >> +set debug compile-oracle >> +show debug compile-oracle >> + Control the display of debug output about symbol requests from >> + the compiler plug-in. >> + >> +set debug compile-cplus-types >> +show debug compile-cplus-types >> + Control the display of debug output about C++ type conversion >> + in the compile feature. > > I suggest to mention that these commands are only available/have > effect if the C++ compilation is supported. Maybe this is better/clearer? set debug compile-cplus-types show debug compile-cplus-types Control the display of debug output about type conversion in the C++ compile feature. Commands have no effect while compiling for other languages. >> +@anchor{set debug compile-oracle} >> +@item set debug compile-oracle >> +@cindex compile oracle debugging info >> +Turns on or off display of symbol requests from the compiler plug-in >> +(the ``oracle''). The default is off. > > @dfn{oracle} should render better. In any case, why do we call this > "the oracle"? In the computing context, "oracle" has connotations > that we don't necessarily want to encourage, I think. Why not > something like "set debug symbol-requests"? This symbol resolver design is called the "oracle" internally (see also references to this name in the Wiki page describing the compile project, https://sourceware.org/gdb/wiki/GCCCompileAndExecute ). Nonetheless, on second thought, it seems almost nonsensical to have a special debug flag just for this. So I've removed the option and just added the "oracle" debug output when the "normal" compile debug flag is set. WDYT? >> +Turns on or off the display of C++ type conversion debugging information. > > Please use C@t{++} for C++ in the text, it renders better in the > printed manual. Done. Would you like me to repost this patch? Keith