From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 50581 invoked by alias); 9 Jan 2019 16:01:02 -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 39138 invoked by uid 89); 9 Jan 2019 16:00:41 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Checked: by ClamAV 0.100.2 on sourceware.org X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS,TIME_LIMIT_EXCEEDED autolearn=unavailable version=3.3.2 spammy=capable, beasts X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS,TIME_LIMIT_EXCEEDED autolearn=unavailable version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on sourceware.org X-Spam-Level: X-HELO: relay6-d.mail.gandi.net Received: from relay6-d.mail.gandi.net (HELO relay6-d.mail.gandi.net) (217.70.183.198) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 09 Jan 2019 16:00:23 +0000 X-Originating-IP: 193.248.54.187 Received: from [192.168.1.2] (lstlambert-656-1-266-187.w193-248.abo.wanadoo.fr [193.248.54.187]) (Authenticated sender: basile@starynkevitch.net) by relay6-d.mail.gandi.net (Postfix) with ESMTPSA id 9C647C0008; Wed, 9 Jan 2019 16:00:16 +0000 (UTC) Subject: Re: about header file parsing To: =?UTF-8?Q?Marc_Nieper-Wi=c3=9fkirchen?= , David Malcolm Cc: akrl , jit@gcc.gnu.org References: <85568212-cec8-f8c8-2941-8db5d19e2989@starynkevitch.net> <1547048594.7788.120.camel@redhat.com> From: Basile Starynkevitch Message-ID: <3e509ad7-a3bd-94b2-ec77-46ee0c05ec5d@starynkevitch.net> Date: Tue, 01 Jan 2019 00:00:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-IsSubscribed: yes X-SW-Source: 2019-q1/txt/msg00025.txt.bz2 On 1/9/19 4:52 PM, Marc Nieper-Wißkirchen wrote: > How would you handle, for example, gmp's header file? > https://gmplib.org/repo/gmp/file/default/gmp-h.in > > Almost all of the public API is behind #define's. So even if the > gcc_jit_context is filled with the functions that are declared in the > header, one still needs to know the ABI of GMP to know which functions > to call. > > In order to make it work in the general case (if this is at all > possible), I think one has to turn the C frontend of GCC into a > library (like libgccjit has turned the GCC middle/backend into a > library). This hypothetical library X has its own context K that is > populated by expanding and parsing the relevant header files. > > In this context K, we can then ask for expansion of strings of C > tokens (e.g. in expression or statement context). Library X then > returns the expansion in term of, say, a C-specific GENERIC tree, > which can then be converted into/wrapped into a gcc_jit_object. > > -- Marc AndI (Basile) wrote: >>> in practice C macros are very important (and a lot of API for C are >>> using macros, see also macros such as WIFEXITED in wait(2) on some >>> Linux >>> system). >>> >>> We have to admit that C and libgccjit are different "languages" (even >>> if >>> conceptually very close). And a C API is not exactly a set of >>> "objects" >>> that libgccjit can handle. >> They're not the same, but it is important that libgccjit be able to >> interoperate well with C APIs. I'm not sure that general goal is reasonable. libgccjit is already able to interoperate with a library written in C. Unfortunately, a C API is not just a library, but also macros (such as EOF or WIFEXITED), and we cannot expect libgccjit to deal with these. On Linux libgccjit is already capable to call any function in some ELF library which uses the C calling conventions, and that is already excellent. And that limitation is not particular to libgccjit: any implementor of some interpreter or compiler has to deal specially with C macros, and handle them in an ad-hoc way. We have to admit that in general C APIs are complex beasts, even if most of the time they are "simple" enough. Regards -- Basile STARYNKEVITCH == http://starynkevitch.net/Basile opinions are mine only - les opinions sont seulement miennes Bourg La Reine, France