On Mon, May 16, 2022 at 2:38 PM Alexander Monakov <amona...@ispras.ru> wrote: > > On Mon, 16 May 2022, Rui Ueyama wrote: > > > If it is a guaranteed behavior that GCC of all versions that support > > only get_symbols_v2 don't leave a temporary file behind if it is > > suddenly disrupted during get_symbols_v2 execution, then yes, mold can > > restart itself when get_symbols_v2 is called for the first time. > > > > Is this what you want? I'm fine with that approach if it is guaranteed > > to work by GCC developers. > > I cannot answer that, hopefully someone in Cc: will. This sub-thread started > with Richard proposing an alternative solution for API level discovery [1] > (invoking onload twice, first with only the _v3 entrypoint in the "transfer > vector"), and then suggesting an onload_v2 variant that would allow to > discover which entrypoints the plugin is going to use [2]. > > [1] https://gcc.gnu.org/pipermail/gcc-patches/2022-May/594058.html > [2] https://gcc.gnu.org/pipermail/gcc-patches/2022-May/594059.html > > ... at which point I butted in, because the whole _v3 thing was shrouded in > mystery. Hopefully, now it makes more sense. > > > From my side I want to add that thread-safety remains a major unsolved point. > Compiler driver _always_ adds the plugin to linker command line, so I expect > that if you add a mutex around your claim_file hook invocation, you'll find > that it serializes the linker too much. Have you given some thought to that? > Will you be needing a plugin API upgrade to discover thread-safe entrypoints, > or do you have another solution in mind?
>From my linker's point of view, the easiest way to handle the situation is to implement a logic like this: if (gcc_version >= 12.2) assume that claim_file_hook is thread safe else assume that claim_file_hook is not thread safe And that is also _very_ useful to identify the existence of get_symbols_v3, because we can do the same thing with s/12.2/12.1/.
