From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24049 invoked by alias); 8 Jan 2008 15:29:29 -0000 Received: (qmail 24041 invoked by uid 22791); 8 Jan 2008 15:29:28 -0000 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 08 Jan 2008 15:29:10 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 06B292A969A for ; Tue, 8 Jan 2008 10:29:09 -0500 (EST) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id L2sYVj0OZnHJ for ; Tue, 8 Jan 2008 10:29:08 -0500 (EST) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 2E0FF2A9690 for ; Tue, 8 Jan 2008 10:29:08 -0500 (EST) Received: by joel.gnat.com (Postfix, from userid 1000) id E5068E7ACB; Tue, 8 Jan 2008 07:29:00 -0800 (PST) Date: Tue, 08 Jan 2008 15:29:00 -0000 From: Joel Brobecker To: gdb-patches@sourceware.org Subject: Re: [RFA] Need post-processing of parameters for function calls in Ada Message-ID: <20080108152900.GB11650@adacore.com> References: <20080108143622.GG24614@adacore.com> <20080108150114.GA19378@caradoc.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080108150114.GA19378@caradoc.them.org> User-Agent: Mutt/1.4.2.2i 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 X-SW-Source: 2008-01/txt/msg00133.txt.bz2 Thanks muchly for the quick feedback! > Is this an argument coercion? The right place may be > value_arg_coerce. Indeed. It looks like the two functions are doing the same thing, but for different languages. > If the only problem is that you need the sp, we > could supply it to that function and move the coercion after the stack > frame setup. I don't think this will be a problem even if we need a > function call during argument coercion. (funny that you're talking about function call during argument coercion, that will be my next patch which I just finished ;-). I don't think we'll need to move the argument coercion phase... > This might allow a useful option, to avoid calling malloc when passing > strings to a C function. We can not do that in general, since the > function might save the pointer, but there are some cases (like strcmp). ... unless that is needed to allow calling malloc. But this can be discussed independently, if you prefer. > Really this sort of thing ought to go through the language vector, but > I'm happy leaving that until a second language needs it. I agree. I propose the following: - Add a new la_value_arg_coerce method in the language vector. The prototype would be identical to the current value_arg_coerce but with the added SP. - rename value_arg_coerce c_value_arg_coerce. Possibly move it to c-lang. - Make all languages use c_value_arg_coerce, except for Ada, which would use our own coerce routine. That should take care of everything (except maybe allowing malloc calls). My only concern is that the Ada coerce might be relying on the C coerce routine to handle the simple cases. So I might need to call the C coerce routine at the end of the Ada coerce routine. I need to look deeper into this. What do you think? Thanks, -- Joel