On Sun, May 15, 2022 at 3:53 PM Alexander Monakov <amona...@ispras.ru> wrote: > > On Sun, 15 May 2022, Rui Ueyama wrote: > > [snip] > > > So get_symbols_v3 allows the linker to discard an LTO .o file to solve > > > this. > > > > > > In absence of get_symbols_v3 mold tries to ensure correctness by > > > restarting > > > itself while appending a list of .o files to be discarded to its command > > > line. > > > > > > I wonder if mold can invoke plugin cleanup callback to solve this without > > > restarting. > > > > We can call the plugin cleanup callback from mold, but there are a few > > problems: > > > > First of all, it looks like it is not clear what state the plugin cleanup > > callback resets to. It may reset it to the initial state with which we > > need to restart everything from calling `onload` callback, or it may not > > deregister functions registered by the previous `onload` call. Since the > > exact semantics is not documented, the LLVM gold plugin may behave > > differently than the GCC plugin. > > Ack, that looks risky (and probably unnecessary, see below). > > > Second, if we reset a plugin's internal state, we need to register all > > input files by calling the `claim_file_hook` callback, which in turn calls > > the `add_symbols` callback. But we don't need any symbol information at > > this point because mold already knows what are in LTO object files as it > > calls `claim_file_hook` already on the same sets of files. So the > > `add_symbols` invocations would be ignored, which is a waste of resources. > > > > So, I prefer get_symbols_v3 over calling the plugin cleanup callback. > > Oh, to be clear I wouldn't argue against implementing get_symbols_v3 in GCC. > I was wondering if mold can solve this in another fashion without the > self-restart trick. > > If I understood your design correctly, mold disregards the index in static > archives, because it doesn't give you the dependency graph of contained > objects (it only lists defined symbols, not used, I was mistaken about that > in the previous email), and you wanted to let mold parse all archived > objects in parallel instead of doing a multiphase scan where each phase > extracts only the needed objects (in parallel). Is that correct?
Correct. > 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? 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. 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. > And with the index, it should be rare that a file is spuriously added to the > plugin, so maybe you could get away with issuing a warning or an error when > the v2 API is used, but mold needs to discard a file? > > > > (also, hm, it seems to confirm my idea that LTO .o files should have had > > > the > > > correct symbol table so normal linker algorithms would work) > > > > I agree. If GCC LTO object file contains a correct ELF symbol table, we > > can also eliminate the need of the special LTO-aware ar command. It looks > > like it is a very common error to use an ar command that doesn't > > understand the LTO object file, which results in mysterious "undefined > > symbol" errors even though the object files in an archive file provide > > that very symbols. > > Thanks. > Alexander
