[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Thu, 9 May 2024 09:51:35 -0400
From: Rich Felker <dalias@...c.org>
To: Maxim Blinov <maxim.a.blinov@...il.com>
Cc: musl@...ts.openwall.com
Subject: Re: IFUNC support
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
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.
