> On Mon, May 2, 2022 at 10:51 AM Richard Biener > <richard.guent...@gmail.com> wrote: > > > > On Mon, May 2, 2022 at 10:19 AM Martin Liška <mli...@suse.cz> wrote: > > > > > > On 5/2/22 10:09, Richard Biener wrote: > > > > On Mon, May 2, 2022 at 9:52 AM Martin Liška <mli...@suse.cz> wrote: > > > >> > > > >> Hi. > > > >> > > > >> This in a new plug-in function that helps identifying compiler > > > >> by a linker. Will be used in mold linker. > > > >> > > > >> Patch can bootstrap on x86_64-linux-gnu and survives regression tests. > > > >> > > > >> Ready to be installed? > > > > > > > > It looks a bit backward to query the compiler (and even more so to > > > > have a fixed set) from the linker. What is this going to be used for? > > > > > > It's going to be used by mold, there are small behavior divergence > > > in between LLVM and GCC, where one compiler closes provided file > > > descriptors: > > > https://github.com/rui314/mold/blob/a15f3875269b575d024725590ae3ef87b611b8d8/elf/lto.cc#L545-L550 > > > > But that then seems to be a defect in the plugin API specification (or > > one of the two implementations). Instead of adding a new API entry > > that defect should be fixed - both require changes in the actual plugin > > specification. > > implementation of course.
I agree that implementation should be fixed. The version query however makes sense to me. It makes it possible for linker to work around bugs of older compilers while implementing features that in general rely on corrected behaviour. I however also find bit odd to have fixed list gcc and llvm. The plugin API (when implemented without bugs) should be compler independent. In this case it would make more sense to have string for compiler name. I think Martin was following existing API for querying linker type which has same oddity and uses enum to represent known linkers supporting the plugin API? Honza
