From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7027 invoked by alias); 5 Mar 2004 08:15:29 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 6966 invoked from network); 5 Mar 2004 08:15:27 -0000 Received: from unknown (HELO nile.gnat.com) (205.232.38.5) by sources.redhat.com with SMTP; 5 Mar 2004 08:15:27 -0000 Received: from localhost (localhost [127.0.0.1]) by nile.gnat.com (Postfix) with ESMTP id A76B2F2DDD; Fri, 5 Mar 2004 03:15:26 -0500 (EST) Received: from nile.gnat.com ([127.0.0.1]) by localhost (nile.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 11626-01-6; Fri, 5 Mar 2004 03:15:26 -0500 (EST) Received: by nile.gnat.com (Postfix, from userid 1345) id 4FAE5F2E13; Fri, 5 Mar 2004 03:15:26 -0500 (EST) From: Paul Hilfinger To: drow@false.org Cc: gdb-patches@sources.redhat.com In-reply-to: <20040304222942.GB29911@nevyn.them.org> (message from Daniel Jacobowitz on Thu, 4 Mar 2004 17:29:42 -0500) Subject: Re: [RFA] Add language-dependent post-parser References: <20040304113345.5DADDF2EDC@nile.gnat.com> <20040304222942.GB29911@nevyn.them.org> Message-ID: <20040305081526.4FAE5F2E13@nile.gnat.com> Date: Fri, 19 Mar 2004 00:09:00 -0000 X-Virus-Scanned: by amavisd-new at nile.gnat.com X-SW-Source: 2004-03/txt/msg00099.txt.bz2 Message-ID: <20040319000900.rFgzz3Ke3qQutDElXDplEFERIVVhJJ24JbPnQC3Tjvs@z> > Could you explain more about why you found this necessary? It's hard > to evaluate the patch without that. Daniel, Sure. In Ada mode, we handle overloaded functions (not just those that are the Ada equivalent of member functions). More precisely, we resolve overloading that can be resolved bottom-up, as C++ (almost always) does. The issue we encountered was the point at which GDB discovers it cannot resolve the overloading. With a command such as print f(3) there is no problem: you can resolve during execution, and print an error message (or whatever) then. But what about cond 1 (f(3) > 12) ? In similar C++ examples, such as cond 1 (A.f(3) > 12) you'll find that resolution problems are reported when the breakpoint is hit, possibly long after the breakpoint is set. This is safe (the program stops), but we felt it was somewhat annoying that one didn't notice the problem earlier. We perform resolution in the obvious way, but that calls for determining the static types of the arguments. While it is possible to do so during parsing, it would mean partially rebuilding the existing infrastructure that allows GDB to compute types and expression values. We thought it would be easier to operate on the same prefix form that is used for evaluation. Unfortunately, this happens only AFTER the language-dependent parser returns. Paul Hilfinger Ada Core Technologies, Inc.