On Sun, May 15, 2022 at 4:51 PM Alexander Monakov <amona...@ispras.ru> wrote: > > On Sun, 15 May 2022, Rui Ueyama wrote: > > > > Is that a good tradeoff in the LTO case though? I believe you cannot > > > assume > > > the plugin to be thread-safe, so you're serializing its API calls, right? > > > But the plugin is doing a lot of work, so using the index to feed it with > > > as > > > few LTO objects as possible should be a significant win, no? (even if it > > > was thread-safe) > > > > Oh, I didn't know that claim_file_hook isn't thread-safe. I need to add a > > lock to guard it then. But is it actually the case? > > You can see for yourself at > https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=lto-plugin/lto-plugin.c > (e.g. how claim_file_handler increments the global variable num_claimed_files) > > > As to the tradeoff, speculatively loading all object files from archives > > may not be beneficial if the loaded files are LTO object files. But we do > > this for consistency. We don't have a multi-phase name resolution pass at > > all in mold; all symbols are resolved at once in parallel. We don't want > > to implement another name resolution pass just for LTO for the following > > reasons: > > > > 1. It bloats up the linker's code. > > > > 2. We don't know whether an archive file contains an LTO object file or > > not until we actually read archive members, so there's no chance to switch > > to the multi-pass name resolution algorithm before we read files. > > > > 3. If we have two different name resolution algorithms, it is very hard to > > guarantee that both algorithms produce the same result. As a result, the > > output with -flto may behave differently without -flto. > > Well, -flto can result in observably different results for other reasons > anyway. > > > 4. We still have to handle --start-libs and --end-libs, so feeding an > > object file that will end up not being included into the output is > > unavoidable. > > Makes sense, but I still don't understand why mold wants to discover in > advance whether the plugin is going to use get_symbols_v3. How would it > help with what mold does today to handle the _v2 case?
Currently, mold restarts itself to reset the internal state of the plugin. If we know in advance that get_symbols_v3 is supported, we can avoid that restart. That should make the linker a bit faster. Also, restarting the linker is a hack, so we want to avoid it if possible.
