[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 9 May 2024 14:16:44 +0100
From: Maxim Blinov <maxim.a.blinov@...il.com>
To: Rich Felker <dalias@...c.org>
Cc: musl@...ts.openwall.com
Subject: Re: IFUNC support
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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
