From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 63165 invoked by alias); 21 Sep 2017 18:29:57 -0000 Mailing-List: contact jit-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Subscribe: Sender: jit-owner@gcc.gnu.org Received: (qmail 63095 invoked by uid 89); 21 Sep 2017 18:29:56 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Checked: by ClamAV 0.99.2 on sourceware.org X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=no version=3.3.2 spammy=weakness, harvard, Harvard, obtaining X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on sourceware.org X-Spam-Level: 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; Thu, 21 Sep 2017 18:29:55 +0000 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 09E97882FB; Thu, 21 Sep 2017 18:29:54 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 09E97882FB Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=dmalcolm@redhat.com Received: from ovpn-116-98.phx2.redhat.com (ovpn-116-98.phx2.redhat.com [10.3.116.98]) by smtp.corp.redhat.com (Postfix) with ESMTP id A80F55D9CD; Thu, 21 Sep 2017 18:29:53 +0000 (UTC) Message-ID: <1506018592.10251.23.camel@redhat.com> Subject: Re: Function pointer handling From: David Malcolm To: Bartosz Szreder , jit@gcc.gnu.org Date: Sun, 01 Jan 2017 00:00:00 -0000 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.28]); Thu, 21 Sep 2017 18:29:54 +0000 (UTC) X-IsSubscribed: yes X-SW-Source: 2017-q3/txt/msg00018.txt.bz2 On Thu, 2017-09-21 at 17:43 +0200, Bartosz Szreder wrote: > I have some questions regarding pointers to functions in current > (7.2) > version of GCC-JIT. > > 1. The documentation doesn't mention existence of > gcc_jit_context_new_function_ptr_type() as a mechanism of handling > function pointers, yet contains > gcc_jit_context_new_call_through_ptr(). Oops; looks like I forgot to document the former. > - Is the former function unsupported/buggy in some way and is not > indented for general use, or just lacks proper documentation? It's just missing documentation. I'm working on fixing it. Have a look at gcc/testsuite/jit.dg/test-calling-function-ptr.c e.g.: https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/testsuite/jit.dg/test-calling-function-ptr.c;h=e21bd15e303f8cfcd37d2eeb294188cc6702066f;hb=HEAD > - What is the proper way of obtaining a function pointer to be passed > to gcc_jit_context_new_call_through_ptr()? There doesn't seem to be > any counterpart to gcc_jit_lvalue_get_address() for functions. As the > name suggests, gcc_jit_lvalue_get_address() works on an L-value and > gcc_jit_function type isn't an ancestor of gcc_jit_lvalue in the > internal type system, therefore upcasting is impossible. If it's a pre-existing function, then you can take its address in your C code, and then use gcc_jit_context_new_rvalue_from_ptr, which assumes that function pointers can be cast to void *, but it's very rare for that not to hold (Harvard architecture, where code and data are disjoint). If it's a function that's being compiled as part of the same gcc_jit_context, then I think you've identified a weakness in the current API. As you say, one fix would be to make gcc_jit_function be a subclass of gcc_jit_lvalue (and add casting functions); I don't yet know how easy that would be to implement. > 2. Is it safe to pass a function pointer as a GCC_JIT_TYPE_VOID_PTR > and use gcc_jit_context_new_call_through_ptr() on such value? It uses the type of the function pointer when building the call, so the function pointer needs to be of a type created using gcc_jit_context_new_function_ptr_type. You may be able to get away with adding casts, but the casting API is rather fussy compared to the rules in C. Hope this is helpful Dave