* [musl] IFUNC support @ 2024-05-09 11:04 Maxim Blinov 2024-05-09 12:35 ` Rich Felker 0 siblings, 1 reply; 4+ messages in thread From: Maxim Blinov @ 2024-05-09 11:04 UTC (permalink / raw) To: musl Hi all, I just wanted to clarify the current status on IFUNCs, specifically when generated by the compiler when using the `target_clones` c function attribute. Am I correct that this is not currently supported by musl? If so, would musl ever support this feature, or is it rejected as a matter of principle? And lastly, if it is possible, what would it take to support this feature? I googled around for some previous discussions on the subject and found https://www.openwall.com/lists/musl/2022/08/23/7, and also https://www.openwall.com/lists/musl/2014/11/11/2, which reports IFUNCs as "One feature musl intentionally does not yet support", but I suppose I wanted to ask again since this was from 2014 and perhaps something has changed since then. I originally stumbled on this issue by observing that the musl dynamic linker, for x86_64, currently errors out on IFUNC symbols with ``` unknown relocation 37 ``` And on RISC-V it throws up with ``` unsupported relocation type 58 ``` which corresponds with the R_RISCV_IRELATIVE relocation. BR, Maxim ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [musl] IFUNC support 2024-05-09 11:04 [musl] IFUNC support Maxim Blinov @ 2024-05-09 12:35 ` Rich Felker 2024-05-09 13:16 ` Maxim Blinov 0 siblings, 1 reply; 4+ messages in thread From: Rich Felker @ 2024-05-09 12:35 UTC (permalink / raw) To: Maxim Blinov; +Cc: musl On Thu, May 09, 2024 at 12:04:28PM +0100, Maxim Blinov wrote: > Hi all, > > I just wanted to clarify the current status on IFUNCs, specifically > when generated by the compiler when using the `target_clones` c > function attribute. > > Am I correct that this is not currently supported by musl? If so, > would musl ever support this feature, or is it rejected as a matter of > principle? And lastly, if it is possible, what would it take to > support this feature? > > I googled around for some previous discussions on the subject and > found https://www.openwall.com/lists/musl/2022/08/23/7, and also > https://www.openwall.com/lists/musl/2014/11/11/2, which reports IFUNCs > as "One feature musl intentionally does not yet support", but I > suppose I wanted to ask again since this was from 2014 and perhaps > something has changed since then. If anything, exclusion of IFUNC is more definite now than in 2014. They keep showing up as vectors for things to break or even for disguising backdoors, and none of the prior reasons for excluding it are really resolvable, nor does it have any performance value over doing things portably with function pointers. > I originally stumbled on this issue by observing that the musl dynamic > linker, for x86_64, currently errors out on IFUNC symbols with > > ``` > unknown relocation 37 > ``` > > And on RISC-V it throws up with > > ``` > unsupported relocation type 58 > ``` > > which corresponds with the R_RISCV_IRELATIVE relocation. It sounds like you have an XY problem: wanting target_clones to work. If GCC was built correctly targeting musl, it should not support ifunc generation at all; you shouldn't end up with unknown relocations in an output binary because the compiler should never have emitted them. I'm not sure, but I think GCC has mechanisms to make this functionality work in the absence of ifunc. If not, maybe it could be enhanced to do so. Rich ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [musl] IFUNC support 2024-05-09 12:35 ` Rich Felker @ 2024-05-09 13:16 ` Maxim Blinov 2024-05-09 13:51 ` Rich Felker 0 siblings, 1 reply; 4+ messages in thread From: Maxim Blinov @ 2024-05-09 13:16 UTC (permalink / raw) To: Rich Felker; +Cc: musl Hi Rich, thanks for your reply, > It sounds like you have an XY problem: wanting target_clones to work. The way I got into the subject of relocs and IFUNCs, is that clang for musl RISC-V outputs binaries that generate these relocs, and one of the binaries was a test case with resolve_multiver in it. either the compiler or musl was wrong, and i initially guessed (incorrectly) that musl was at fault. > If GCC was built correctly targeting musl, it should not support ifunc > generation at all; you shouldn't end up with unknown relocations in an > output binary because the compiler should never have emitted them. That's my conclusion aswell. so far in my testing when building something with target_clones, or resolve_multiver, I see: - gcc for musl, x86_64: errors out - gcc for musl, riscv: generates binary with IFUNCs - clang for musl, x86_64: generates binary with IFUNCs - clang for musl, riscv: generates binary with IFUNCs For the LLVM side, I've opened an issue against LLVM about this (although I'm still not 200% sure its not a misconfiguration on my end.), link: https://github.com/llvm/llvm-project/issues/91313. LLVM currently appears to generate IFUNCs regardless. i admit i haven't yet properly dug around in a debugger to figure out why. For the gcc side, the reason i believe is as below: gcc x86_64 does the right thing: gcc/configure.ac imports gcc/config.gcc, which has logic[1] that turns off IFUNC support if we're targeting a triple that ends in `musl`. The resultant compiled gcc will error out if you try to use the feature. This is applied to all triples ending in `musl`, so in theory that should be the end of discussion. but gcc for *RISC-V* doesn't, because the logic for checking whether or not we have support for IFUNCS is overridden *after* gcc/config.gcc has been parsed, in gcc/configure.ac [2], by: - assembling a test assembly file with a `.type foo, %gnu_indirect_function`, - linking, - objdumping the binary and greping for `R_RISCV_IRELATIVE` well, i suppose outsourcing the logic to gnu ld is not unreasonable, but does it mean that gnu ld targeting anything ending in `musl` should throw up at the sight of `gnu_indirect_function`? [1]: https://github.com/gcc-mirror/gcc/blob/2790195500ec523cad9c7292816540e2fc19f456/gcc/config.gcc#L3670-L3684 [2]: https://github.com/gcc-mirror/gcc/blob/2790195500ec523cad9c7292816540e2fc19f456/gcc/configure.ac#L3057-L3107 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [musl] IFUNC support 2024-05-09 13:16 ` Maxim Blinov @ 2024-05-09 13:51 ` Rich Felker 0 siblings, 0 replies; 4+ messages in thread From: Rich Felker @ 2024-05-09 13:51 UTC (permalink / raw) To: Maxim Blinov; +Cc: musl On Thu, May 09, 2024 at 02:16:44PM +0100, Maxim Blinov wrote: > Hi Rich, thanks for your reply, > > > It sounds like you have an XY problem: wanting target_clones to work. > > The way I got into the subject of relocs and IFUNCs, is that clang for > musl RISC-V outputs binaries that generate these relocs, and one of > the binaries was a test case with resolve_multiver in it. either the > compiler or musl was wrong, and i initially guessed (incorrectly) that > musl was at fault. > > > If GCC was built correctly targeting musl, it should not support ifunc > > generation at all; you shouldn't end up with unknown relocations in an > > output binary because the compiler should never have emitted them. > > That's my conclusion aswell. so far in my testing when building > something with target_clones, or resolve_multiver, I see: > > - gcc for musl, x86_64: errors out > - gcc for musl, riscv: generates binary with IFUNCs > - clang for musl, x86_64: generates binary with IFUNCs > - clang for musl, riscv: generates binary with IFUNCs > > For the LLVM side, I've opened an issue against LLVM about this > (although I'm still not 200% sure its not a misconfiguration on my > end.), link: https://github.com/llvm/llvm-project/issues/91313. LLVM > currently appears to generate IFUNCs regardless. i admit i haven't yet > properly dug around in a debugger to figure out why. > > For the gcc side, the reason i believe is as below: > > gcc x86_64 does the right thing: gcc/configure.ac imports > gcc/config.gcc, which has logic[1] that turns off IFUNC support if > we're targeting a triple that ends in `musl`. The resultant compiled > gcc will error out if you try to use the feature. This is applied to > all triples ending in `musl`, so in theory that should be the end of > discussion. > > but gcc for *RISC-V* doesn't, because the logic for checking whether > or not we have support for IFUNCS is overridden *after* gcc/config.gcc > has been parsed, in gcc/configure.ac [2], by: > - assembling a test assembly file with a `.type foo, %gnu_indirect_function`, > - linking, > - objdumping the binary and greping for `R_RISCV_IRELATIVE` > > well, i suppose outsourcing the logic to gnu ld is not unreasonable, > but does it mean that gnu ld targeting anything ending in `musl` > should throw up at the sight of `gnu_indirect_function`? > > [1]: https://github.com/gcc-mirror/gcc/blob/2790195500ec523cad9c7292816540e2fc19f456/gcc/config.gcc#L3670-L3684 > [2]: https://github.com/gcc-mirror/gcc/blob/2790195500ec523cad9c7292816540e2fc19f456/gcc/configure.ac#L3057-L3107 I suspect ld tries to avoid having too much of this kind of C implementation policy knowledge. Mechanically, an ELF-based target is able to represent IFUNC relocations even if they won't be usable at runtime; it's generally the compiler's responsibility to produce code that's compatible with the target libc. I think the order of the probes should be inverted, or the second probe should just be skipped if ifunc was already disabled by the first. What ld wants to do with this is a matter independent of the logic bug in gcc's configure. Rich ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2024-05-09 13:51 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2024-05-09 11:04 [musl] IFUNC support Maxim Blinov 2024-05-09 12:35 ` Rich Felker 2024-05-09 13:16 ` Maxim Blinov 2024-05-09 13:51 ` Rich Felker
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/musl/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).