On 5/2/22 11:14, Richard Biener wrote: > On Mon, May 2, 2022 at 11:08 AM Martin Liška <mli...@suse.cz> wrote: >> >> On 5/2/22 11:03, Richard Biener wrote: >>> In fact I think GCC is correct in its handling and LLVM would need to dup >>> () the >>> file descriptor. Was this issue raised with the LLVM folks? >> >> I don't know here. >> >>> I suspect the BFD >>> linker will also not work with LLVM due to this? >> >> I'm not sure BFD is supported by LLVM: >> https://llvm.org/docs/GoldPlugin.html >> >> They explicitly name it Gold plugin. > > BFD does > > if (plugin_call_claim_file (&file, &claimed)) > einfo (_("%F%P: %s: plugin reported error claiming file\n"), > plugin_error_plugin ()); > > if (input->fd != -1 > && (!claimed || !bfd_plugin_target_p (ibfd->xvec))) > { > /* FIXME: fd belongs to us, not the plugin. GCC plugin, which > doesn't need fd after plugin_call_claim_file, doesn't use > BFD plugin target vector. Since GCC plugin doesn't call > release_input_file, we close it here. LLVM plugin, which > needs fd after plugin_call_claim_file and calls > release_input_file after it is done, uses BFD plugin target > vector. This scheme doesn't work when a plugin needs fd and > doesn't use BFD plugin target vector neither. */ > release_plugin_file_descriptor (input); > } > > so it knows about the problem. The above suggests that the plugin > could set ->fd to -1 ...
That would work. So we can add LDPT_REGISTER_CLAIM_FILE_HOOK_V2 hook that will release fd based on if claim_file_v2 resets it to -1 or not. Does it worth implementing? Cheers, Martin > > Richard. > >> >> Martin >>
