mold error when building gcc with lto 'Assertion `!is_v2' failed.' #454
Comments
|
IIRC, @marxin tried to build gcc using mold with LTO, and I believe it worked at the moment. Could it be a regression of gcc? |
|
Well, note the current master (the upcoming |
|
On second thought, it's likely an internal error of mold and not gcc's fault. I just want to confirm that you succeeded to build gcc with mold with LTO recently. If so, it's likely a mold's regression. |
|
Oh, to be honest, I haven't tested LTO bootstrap of GCC (even with the queued packages prepared to GCC 13 like |
|
OK, thank you for confirming! I'll take a look. |
|
But I can confirm I can LTO bootstrap GCC with the GCC patch that introduces |
|
Oh, but I end up with some undefined symbols: |
|
About the but I can't see the That's why we end up with the error. |
|
@marxin What are your configure options? |
|
|
Actually I did again a try and facing in the following error: GCC Version used: gcc version 12.0.1 20220426 (experimental) (GCC) |
|
It's new issue #475. |
|
That problem should be fixed now, so please try again. |
|
The original issue should also be fixed in the above commit. |
|
Stage 1 of the GCC compiler is opened and I've sent the and I was able to LTO bootstrap GCC with all languages enabled: About the other changes mentioned in this thread. GCC community is not happy about the new hook: So I'm leaving that one. Apparently, other linkers also have conditional behavior based on if GCC or Clang is used. |
|
How can I distinguish a GCC plugin with v2-only support from one with v3 support? Currently, mold restart itself if a GCC LTO plugin is in use to reset the internal state of the plugin. That happens before we call If |
|
Or, maybe we can restart the linker as soon as |
rui314
added a commit
that referenced
this issue
May 4, 2022
…irst time Previously, we detected if a given linker plugin supports get_symbols_v3 or not and restart the process if only get_symbols_v2 is supported. Now, mold restart itself wehn get_symbols_v2 is called for the first time, eliminating the need for the feature detection. #454
Oh, I forgot about this need. So if you want I can suggest adding a new symbol |
Yes! That seems more robust than the workaround that I implemented in 38f2b96. |
|
All right, I've suggested that: |
|
I think you should instead try not advertising LDPT_GET_SYMBOLS or LDPT_GET_SYMBOLS_V2 in the onload transfer |
|
As you wrote, since there's no guarantee what the plugin is after |
|
Yes, ideally we'd extend the plugin API to make such retried onload() well-defined, for example by adding onload_v2 () That said, for current API and existing plugins it might be a workable heuristic to call onload() multiple times. For doing changes to the API a clean design is warranted, a global symbol just indicating whether _v3 is used solelyt isn't. |
|
Speaking of the plugin API itself, I found it very peculiar and hard to use. The plugin exports only the So, if adding a symbol doesn't look clean, I'd suggest we redesign the whole plugin API. We should eliminate the global state from the plugin and export more symbols from the plugin. That said, I doubt it would worth the effort. Effectively, this plugin API is used only by GNU ld, GNU gold and mold. For these linkers, adding a marker symbol should suffice, and IMHO it's actually a cleaner solution than using more complicated and unreliable mechanism to detect the presence of v3 API. |
|
I didn't design the API but incremental things should follow the design spirit. So instead of a new "flag" symbol you'd enum ld_plugin_status which would return LDPS_OK for used and LDPS_ERR for not used (or not known) variants. |
|
IMHO, it's an intricate way to obtain a single bit information (whether or not a given plugin supports the v3 API), but defining a new callback will work for us. If it's implemented in GCC LTO plugin, we are happy to use it. |
|
Should be the issue reopened again after reverting the commit? So probably the issue will be present again, right ? Or is just the v3 API affected ? |
|
I will check the current status, but reverting a patch shouldn't harm any existing GCC users. It's that mold now always assumes that gcc supports only the v2 API. |
|
@rui314 Can you please experiment with the latest suggested plug-in extension patches: |
|
Just a quick note, 2 of 3 patches are upstreamed and I'm right now waiting for your feedback about the |
|
@marxin Sorry I was working on mold/macOS. I'll try that this week. |
|
I sent a reply to the gcc-patches mailing list. https://gcc.gnu.org/pipermail/gcc-patches/2022-June/597518.html |
|
Kodi 20.3-Nexus fails to build after mold v2.2.0, I've tested 2.3.x & 2.4.x |
|
@SupervisedThinking How did you build Kodi? I couldn't reproduce the issue. My CMake options are: |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hello @rui314,
First thanks for the great linker!
actually wanted to build gcc with lto and bootstrap and faced into a error, i dont know if its configuring, gcc or mold related but here the error:
used latest mold commit
494b28cfb38c3291adeb7ea4ed1fc64f37846651and gcc-12 `gcc version 12.0.1 20220421 (experimental) GCC', built on archlinux.did built with following configuring flags:
Maybe @marxin could help.
Thanks and Regards.
The text was updated successfully, but these errors were encountered: