From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15719 invoked by alias); 9 Jan 2019 16:25:27 -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 15632 invoked by uid 89); 9 Jan 2019 16:25:27 -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=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:2238, our X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on sourceware.org X-Spam-Level: X-HELO: mail-pf1-f178.google.com Received: from mail-pf1-f178.google.com (HELO mail-pf1-f178.google.com) (209.85.210.178) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 09 Jan 2019 16:25:24 +0000 Received: by mail-pf1-f178.google.com with SMTP id b85so3892687pfc.3 for ; Wed, 09 Jan 2019 08:25:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=svr8eb8RCinWqc6p1wq6PbYcUkEQi2/XMVpjqVbl7O4=; b=YVxLz/DKmkXxr2c0GG3dAOvIYsd7sX4PRY3LiIJiTuoilYV2FlO5WDAL3QKrdMMz8z T+Mc++ObHh6Mn2lqDnBQ4QM1r0O0O/K00yrLfaISb3YhIedY61qKCtXEb3qocY/vzHHh lR9011F7jgZqC9RHBzZ8bunfn9pGTCGLkY3wvWDvalTJRZGbZXrqErNjs56MlcJiu+Ch FG2qIzklSH3Rbt+7OYRitr0RfBu2dEpY+KhdY/GCBReRzJW0hhNoEJQnRJTlAo44EbxT qZtIexyWHKD5+HqagEJ5u9DzGvVfCxtH1IaCBcOgdO56Tj0uiZCEhGJAucip1Jr6DNGF eQ8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=svr8eb8RCinWqc6p1wq6PbYcUkEQi2/XMVpjqVbl7O4=; b=jxPNFFC/edCzALeBzA9nj+PLD88vJ/6Yy3m8P3SbxY3ZDYp62GU7WjhwlSaoiy1Wrl qLNU0dzztHv39wE69HVmnfOppWKyq8E9tOrMmOcRlgq2aEw1Oj67burH8SsA30njJlEB 4jJpfoqL2tXH98Zvbv2C9CeJpOy1JPLqW+Plk2COFh/UG1CjtcnaOMD4T2tIF7JItd/z DM4m5bm6FrFHj4t4o2op27+b5uHsXyMipXQ/7oj2HkU0KPjLJOw6W7OgV5J+PxPIbaPT bz9xRtSAfDJnkimGYmbZW2vbPRABCYqKwoHOGPLJTr31kbP5xN6HDOE+Fn8IruMy5N7x U97g== X-Gm-Message-State: AJcUukd/qekgZLDawuYLGPzLf0xR0yhOYOLWKev7TAuwJuJv7L9UfDGe 2T7IKQB8spCso7o6EopXNbK8uPhupqTxVskAv0c= X-Google-Smtp-Source: ALg8bN71lLXoxH//iyIR6lOpOzu+jnRhoY4Xv5j8y2bjuonnxL9XYfWDnpny6JAruUGpyX2rRuw+VR44vMVVJ+3Ndl8= X-Received: by 2002:a62:5486:: with SMTP id i128mr6395166pfb.215.1547051122611; Wed, 09 Jan 2019 08:25:22 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: =?UTF-8?Q?Marc_Nieper=2DWi=C3=9Fkirchen?= Date: Tue, 01 Jan 2019 00:00:00 -0000 Message-ID: Subject: Re: about header file parsing To: akrl Cc: David Malcolm , Basile Starynkevitch , jit@gcc.gnu.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2019-q1/txt/msg00027.txt.bz2 Am Mi., 9. Jan. 2019 um 17:11 Uhr schrieb akrl : > > Marc Nieper-Wi=C3=9Fkirchen writes: > > > 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 > > So if I undertand correctly: the problem you are raising about defines is > about naming in the sense that to use an API under defines you'll > need to use the the preprocessed expanded names in libgccjit? Exactly. (Of course, more complicated APIs in form of C header files are conceivable.) > If this is the case I still think the tool would be useful. What one could do (without having to take a look into the header file, which is good because the internals are not part of the API) would be to amend the header file by an extra stub. In the case of the EOF example, one couid put static int const jit_eof =3D EOF; in this stub. When the header file and the stub have been processed by our hypothetical tool, the context will have been populated with `jit_eof' (and we rely on the compiler to optimize away the static variable). In the case of gmp.h, where, for example, mpq_numref is a macro, the stub would contain a definition like: static inline void jit_mpq_numref (mpq_t rop, const mpq_t op) { mpq_numref (rop, op); } And so on... -- Marc > Andrea > > -- > akrl@sdf.org