From: Alexander Monakov <amonakov@ispras.ru>
To: Richard Biener <richard.guenther@gmail.com>
Cc: "Martin Liška" <mliska@suse.cz>,
"GCC Patches" <gcc-patches@gcc.gnu.org>,
"Jan Hubicka" <hubicka@ucw.cz>
Subject: Re: [PATCH] lto-plugin: add support for feature detection
Date: Thu, 5 May 2022 13:52:56 +0300 (MSK) [thread overview]
Message-ID: <da61b59-4588-cd97-5ce1-b8c51f7a33a4@ispras.ru> (raw)
In-Reply-To: <CAFiYyc22y-rDGuJ6g=mWEDjcW+uaMRLkXitxYYZgzR+Jse8MPQ@mail.gmail.com>
On Thu, 5 May 2022, Richard Biener via Gcc-patches wrote:
> > I think they should simply try to not register LDPT_GET_SYMBOLS or
> > LDPT_GET_SYMBOLS_V2 with the plugin in the onload hook and if
> > that fails they will know the plugin doesn't support V3 only. I suppose
> > it should work to call onload() multiple times (when only increasing the
> > set of supported functions) until it returns LDPS_OK without intermediately
> > dlclosing it (maybe call cleanup_handler inbertween). This should work
> > for old plugin versions.
> >
> > That said, a better API extension compared to adding some random
> > symbol like you propose is to enhance the return value from onload(),
> > maybe returning an alternate transfer vector specifying symbol entries
> > that will not be used (or return a transfer vector that will be used).
> > We've been mostly versioning the symbol related hooks here.
> >
> > That said, I do not like at all this proposed add of a special symbol
> > to flag exclusive v3 use. That's a hack and not extensible at all.
>
> Speaking of which, onload_v2 would be in order and should possibly
> return some instantiation handle of the plugin that the linker could
> instruct the plugin to dispose (reset ()?). I see the GCC implementation
> of the plugin just has a single global state and it doesn't seem that it's
> prepared for multiple onload() calls (but it might work by accident if
> you never remove things from the support vector but only add).
>
> Without revamping the whole API onload_v2 could set the current
> global state for the plugin based on the transfer vector and the reset()
> API would discard the state (might also be redundant and implicitely
> performed by the next onload_v2 call).
>
> onload_v2 could then also have an "output" transfer vector where the
> plugin simply copies the entries it picked and dropped those it will
> never call. We'd document the plugin may only pick _one_ of the versioned
> API variants.
>
> That said, the heuristic outlined above might still work with the present
> onload() API and existing implementations.
Feels a bit weird to ask, but before entertaining such an API extension,
can we step back and understand the v3 variant of get_symbols? It is not
documented, and from what little I saw I did not get the "motivation" for
its existence (what it is doing that couldn't be done with the v2 api).
To me lack of documentation looks like a serious issue :/
Likewise, I don't really understand why mold cannot be flexible and
efficiently service both the v2 and v3 variants without committing
to one of those in advance.
Alexander
next prev parent reply other threads:[~2022-05-05 10:53 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 [this message]
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
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=da61b59-4588-cd97-5ce1-b8c51f7a33a4@ispras.ru \
--to=amonakov@ispras.ru \
--cc=gcc-patches@gcc.gnu.org \
--cc=hubicka@ucw.cz \
--cc=mliska@suse.cz \
--cc=richard.guenther@gmail.com \
/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).