Re: [musl] IFUNC support

[Maxim Blinov <maxim.a.blinov@gmail.com>]

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