public inbox for jit@gcc.gnu.org
 help / color / mirror / Atom feed
From: "Marc Nieper-Wißkirchen" <marc.nieper@gmail.com>
To: akrl <akrl@sdf.org>
Cc: David Malcolm <dmalcolm@redhat.com>,
	Basile Starynkevitch <basile@starynkevitch.net>,
	jit@gcc.gnu.org
Subject: Re: about header file parsing
Date: Tue, 01 Jan 2019 00:00:00 -0000	[thread overview]
Message-ID: <CAEYrNrRcds3k3ad8zZpzqM06Q5W+PAYA5REsvDN6Y17PyzNW4Q@mail.gmail.com> (raw)
In-Reply-To: <xjf1s5lerpu.fsf@sdf.org>

Am Mi., 9. Jan. 2019 um 17:11 Uhr schrieb akrl <akrl@sdf.org>:
>
> Marc Nieper-Wißkirchen <marc.nieper@gmail.com> 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 = 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

  reply	other threads:[~2019-01-09 16:25 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-01  0:00 akrl
2019-01-01  0:00 ` Basile Starynkevitch
2019-01-01  0:00   ` Marc Nieper-Wißkirchen
2019-01-01  0:00     ` Marc Nieper-Wißkirchen
2019-01-01  0:00       ` David Malcolm
2019-01-01  0:00         ` Marc Nieper-Wißkirchen
2019-01-01  0:00           ` akrl
2019-01-01  0:00             ` David Malcolm
2019-01-01  0:00               ` akrl
2019-01-01  0:00                 ` Marc Nieper-Wißkirchen
2019-01-01  0:00                   ` akrl
2019-01-01  0:00                     ` Marc Nieper-Wißkirchen
2019-01-01  0:00                       ` akrl
2019-01-01  0:00                         ` Marc Nieper-Wißkirchen
2019-01-01  0:00                           ` akrl
2019-01-01  0:00           ` David Malcolm
2019-01-01  0:00   ` Marc Nieper-Wißkirchen
2019-01-01  0:00 ` David Malcolm
2019-01-01  0:00   ` akrl
2019-01-01  0:00     ` Basile Starynkevitch
2019-01-01  0:00       ` akrl
2019-01-01  0:00         ` Basile Starynkevitch
2019-01-01  0:00           ` David Malcolm
2019-01-01  0:00             ` Marc Nieper-Wißkirchen
2019-01-01  0:00               ` akrl
2019-01-01  0:00                 ` Marc Nieper-Wißkirchen [this message]
2019-01-01  0:00               ` Basile Starynkevitch
2019-01-01  0:00       ` David Malcolm
2019-01-01  0:00     ` David Malcolm
2019-01-01  0:00       ` akrl
2019-01-01  0:00         ` David Malcolm
     [not found] <df8944b7-1fbe-b56f-cc48-ab926d0cb5ad@starynkevitch.net>
2019-01-01  0:00 ` Basile Starynkevitch
2019-01-01  0:00   ` Marc Nieper-Wißkirchen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAEYrNrRcds3k3ad8zZpzqM06Q5W+PAYA5REsvDN6Y17PyzNW4Q@mail.gmail.com \
    --to=marc.nieper@gmail.com \
    --cc=akrl@sdf.org \
    --cc=basile@starynkevitch.net \
    --cc=dmalcolm@redhat.com \
    --cc=jit@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).