Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 9 May 2024 14:16:44 +0100
From: Maxim Blinov <>
To: Rich Felker <>
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: 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/ 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

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/ [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`?


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.