From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 68732 invoked by alias); 17 Nov 2017 11:32:20 -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 68611 invoked by uid 89); 17 Nov 2017 11:32:20 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.7 required=5.0 tests=BAYES_00,KB_WAM_FROM_NAME_SINGLEWORD,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=no version=3.3.2 spammy=philosophy, H*f:sk:4bca71a, difficulties, H*f:sk:d4fd34d 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 Nov 2017 11:32:19 +0000 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id B82B6FC7CA; Fri, 17 Nov 2017 11:32:17 +0000 (UTC) Received: from [127.0.0.1] (ovpn04.gateway.prod.ext.ams2.redhat.com [10.39.146.4]) by smtp.corp.redhat.com (Postfix) with ESMTP id E9E5A60F8A; Fri, 17 Nov 2017 11:32:16 +0000 (UTC) Subject: Re: RFC: problems with minimal symbols (without a type) To: Joel Brobecker References: <20171109012540.ds5ixw4pq6rclhgc@adacore.com> <4bca71af-2877-2adf-9f54-e51d7e6b5b8b@redhat.com> <20171115013531.cwj5pzjttrihofhl@adacore.com> <20171115185204.qku477ejfyescpie@adacore.com> Cc: gdb-patches@sourceware.org From: Pedro Alves Message-ID: <4978e1ba-ecfe-15ad-5532-5cf543498543@redhat.com> Date: Fri, 17 Nov 2017 11:32:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <20171115185204.qku477ejfyescpie@adacore.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2017-11/txt/msg00334.txt.bz2 On 11/15/2017 06:52 PM, Joel Brobecker wrote: >> This is to follow usual language rules. A cast expression isn't >> an lvalue, so you can't take its address: > > Ah, ok. > > My philosophy is been that it's OK, and sometimes good, to allow > in the debugger something that's not allowed in the language, if > it makes it easier for the user to do his debugging. Would allowing > this as an extension be introducing possible confusion? Sorry, somehow I missed this question. I agree that sometimes extensions are OK, but IMO, they need to have some clear advantage. Since there's a just-as-easy way to do the same thing within the language, IMO, we shouldn't add such an extension. I think that yes, it can introduce confusion, and I could see someone reporting a bug if they notice "&(int)global" works. Extending the language always has risk of conflicting with future revisions of the language, or running into cases that we can't make work, kind of painting ourselves into an odd corner. For example, consider the case of the "compile" command, when we pass the expression to a real compiler to parse. Ideally we'll teach the gcc C/C++ frontends about all our syntax extensions somehow (e.g, behind some special "#pragma GCC gdb_extensions" or something in the code we hand over to the compiler), so that "compile print" can become a strict superset of "print". IMO we'd even ditch our internal C/C++ parser and always go via the compiler (though we're still far from being able to do that). This extension sounds like the kind that would run into implementation difficulties and maybe "language-lawer-ish"-resistance in GCC. In this case, taking the address of an rvalue expression never worked, even with debug info for the symbol at hand, so IMO adding such a feature would/should be considered as an orthogonal enhancement. Thanks, Pedro Alves