From: Richard Biener <richard.guenther@gmail.com>
To: Jan Hubicka <hubicka@kam.mff.cuni.cz>
Cc: "Martin Liška" <mliska@suse.cz>,
"Alexander Monakov" <amonakov@ispras.ru>,
"GCC Patches" <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH] lto-plugin: add support for feature detection
Date: Mon, 16 May 2022 12:22:24 +0200 [thread overview]
Message-ID: <CAFiYyc1XW2WzN0MrHzEjtpjV8geAB+1KnB0A_nm+RVt7Rt8f3w@mail.gmail.com> (raw)
In-Reply-To: <YoIeWbpps4s2ZSa1@kam.mff.cuni.cz>
On Mon, May 16, 2022 at 11:50 AM Jan Hubicka <hubicka@kam.mff.cuni.cz> wrote:
>
> > On 5/16/22 11:25, Jan Hubicka via Gcc-patches wrote:
> > >>
> > >> Sure having a 'plugin was compiled from sources of the GCC N.M compiler'
> > >> is useful if bugs are discovered in old versions that you by definition cannot
> > >> fix but can apply workarounds to. Note the actual compiler used might still
> > >> differ. Note that still isn't clean API documentation / extension of the plugin
> > >> API itself. As of thread safety we can either add a claim_file_v2_hook
> > >> or try to do broader-level versioning of the API with a new api_version
> > >> hook which could also specify that with say version 2 the plugin will
> > >> not use get_symbols_v2 but only newer, etc. The linker would announce
> > >> the API version it likes to use and the plugin would return the
> > >> (closest) version
> > >> it can handle. A v2 could then also specify that claim_file needs to be
> > >
> > > Yep, I think having the API version handshake is quite reasonable way to
> > > go as the _v2,_v3 symbols seems already getting bit out of hand and we
> > > essentially have 3 revisions of API to think of
> > > (first adding LDPR_PREVAILING_DEF_IRONLY_EXP, second adding
> > > GET_SYMBOLS_V3 and now we plan third adding thread safety and solving
> > > the file handler problems)
> >
> > How should be design such a version handshake?
>
> As richi outlined. We need to assign version number of the API (with 1,
> 2, 3 defind to match existing revisions) and define version 4 which will
> have have way for plugin to announce maximal api version supported and
> linker telling plugin what API version it wants to work with. That
> shold be min(linker_api, plugin_api)
>
> Since revisions happens relatively rarely, I think we should be able to
> stay with single number determining it.
> >
> > >
> > >> thread safe, or that cleanup should allow a followup onload again with
> > >> a state identical to after dlopen, etc.
> > >>
> > >> Is there an API document besides the header itself somewhere?
> > >
> > > There is https://gcc.gnu.org/wiki/whopr/driver
> > > I wonder if this can't be moved into more official looking place since
> > > it looks like it is internal to GCC WHOPR implementation this way.
> >
> > We can likely add it here:
> > https://gcc.gnu.org/onlinedocs/gccint/LTO.html#LTO
> >
> > What do you think? I can port it.
>
> I am bit worried that it is place LLVM developers will not look at
> since name "GCC internals" suggests it is internal to GCC. It is
> not. However perhaps we can link it from binutils docs, plugin header
> and gcc plugin source to make it hopefully obvious enough. Maybe
> binutils docs would be an alternative. Yet we want other linkers support
> it: I am really happy mold now supports plugin API, but if lld and MacOS
> linker had it it would make our life easier.
Yep. Or if the docs are not too extensive pasting them into
plugin-api.h itself might be not the worst idea either ... basically
provide markup that doxygen or similar tools can re-create sth
like the wiki page?
Richard.
> Honza
> >
> > Martin
> >
> > >
> > > Honza
> > >>
> > >> Richard.
> >
next prev parent reply other threads:[~2022-05-16 10:22 UTC|newest]
Thread overview: 76+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-02 7:51 [PATCH] Support LDPT_GET_SYMBOLS_V3 Martin Liška
2022-05-04 12:20 ` [PATCH] lto-plugin: add support for feature detection Martin Liška
2022-05-04 12:32 ` Alexander Monakov
2022-05-04 12:41 ` Martin Liška
2022-05-04 13:10 ` Alexander Monakov
2022-05-04 13:31 ` Martin Liška
2022-05-04 15:06 ` Bernhard Reutner-Fischer
2022-05-05 6:15 ` Richard Biener
2022-05-05 6:31 ` Richard Biener
2022-05-05 10:52 ` Alexander Monakov
2022-05-05 12:50 ` Martin Liška
2022-05-06 14:46 ` Alexander Monakov
2022-05-09 9:05 ` Martin Liška
2022-05-15 6:57 ` Rui Ueyama
2022-05-15 7:53 ` Alexander Monakov
2022-05-15 8:07 ` Rui Ueyama
2022-05-15 8:50 ` Alexander Monakov
2022-05-15 10:01 ` Rui Ueyama
2022-05-15 10:09 ` Alexander Monakov
2022-05-15 10:32 ` Rui Ueyama
2022-05-15 11:37 ` Alexander Monakov
2022-05-15 11:52 ` Rui Ueyama
2022-05-15 12:07 ` Alexander Monakov
2022-05-16 2:41 ` Rui Ueyama
2022-05-16 6:38 ` Alexander Monakov
2022-05-16 8:37 ` Rui Ueyama
2022-05-16 9:10 ` Richard Biener
2022-05-16 9:15 ` Alexander Monakov
2022-05-16 9:25 ` Jan Hubicka
2022-05-16 9:38 ` Martin Liška
2022-05-16 9:50 ` Jan Hubicka
2022-05-16 10:22 ` Richard Biener [this message]
2022-05-16 9:58 ` Rui Ueyama
2022-05-16 10:28 ` Richard Biener
2022-05-16 10:44 ` Rui Ueyama
2022-05-16 12:04 ` Martin Liška
2022-05-16 13:07 ` Rui Ueyama
2022-05-16 13:38 ` Alexander Monakov
2022-05-16 15:16 ` Alexander Monakov
2022-05-17 6:20 ` Richard Biener
2022-05-17 13:44 ` Martin Liška
2022-06-16 6:59 ` [PATCH 1/3] lto-plugin: support LDPT_GET_SYMBOLS_V3 Martin Liška
2022-06-20 9:23 ` Richard Biener
2022-06-16 7:01 ` [PATCH 2/3] lto-plugin: make claim_file_handler thread-safe Martin Liška
2022-06-20 9:32 ` Richard Biener
2022-06-20 10:20 ` Martin Liška
2022-06-21 7:56 ` Richard Biener
2022-06-21 8:43 ` Martin Liška
2022-06-24 8:37 ` Richard Biener
2022-06-16 7:01 ` [PATCH 3/3] lto-plugin: implement LDPT_GET_API_VERSION Martin Liška
2022-06-16 8:00 ` Alexander Monakov
2022-06-16 12:25 ` Martin Liška
2022-06-20 9:35 ` Richard Biener
2022-06-20 13:01 ` Martin Liška
2022-06-30 6:43 ` Rui Ueyama
2022-06-30 8:42 ` Martin Liška
2022-07-01 6:36 ` Richard Biener
2022-07-04 14:17 ` Martin Liška
2022-07-07 2:19 ` Rui Ueyama
2022-07-08 8:42 ` Martin Liška
2022-07-08 12:41 ` Alexander Monakov
2022-07-11 7:23 ` Rui Ueyama
2022-07-11 9:16 ` Alexander Monakov
2022-07-11 9:55 ` Richard Biener
2022-07-11 10:51 ` Martin Liška
2022-07-11 12:24 ` Rui Ueyama
2022-07-11 12:38 ` Alexander Monakov
2022-07-11 12:51 ` Martin Liška
2022-07-12 1:36 ` Rui Ueyama
2022-07-11 16:35 ` Alexander Monakov
2022-07-12 6:28 ` Richard Biener
2022-07-12 7:36 ` Martin Liška
2022-07-12 11:50 ` Rui Ueyama
2022-07-12 13:21 ` Richard Biener
2022-07-12 13:31 ` Martin Liška
2022-07-13 7:44 ` Rui Ueyama
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=CAFiYyc1XW2WzN0MrHzEjtpjV8geAB+1KnB0A_nm+RVt7Rt8f3w@mail.gmail.com \
--to=richard.guenther@gmail.com \
--cc=amonakov@ispras.ru \
--cc=gcc-patches@gcc.gnu.org \
--cc=hubicka@kam.mff.cuni.cz \
--cc=mliska@suse.cz \
/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).