ibookstein added a comment.
Hmm. When I try to compile an object file where the resolver is a declaration,
both clang-13, clang-14, and gcc-9.3 complain that the ifunc must point to a
defined function:
void *foo_resolver();
void foo(void) __attribute__((ifunc("foo_resolver")));
clang (13 and 14) complain:
obj.c:2:31: error: ifunc must point to a defined function
void foo(void) __attribute__((ifunc("foo_resolver")));
^
1 error generated.
gcc 9.3.0 complains:
obj.c:3:6: error: ‘foo’ aliased to undefined symbol ‘foo_resolver’
3 | void foo(void) __attribute__((ifunc("foo_resolver")));
| ^~~
I realize that the fact that frontends reject this doesn't necessarily mean
that the IR they would have hypothetically produced is invalid, I'm just
wondering about the semantics.
Drawing some parallels to GlobalAliases, you'll see that they also check that
the aliasee is a definition rather than a declaration
(`Verifier::visitAliaseeSubExpr`), which was the reason I added the same check
to `Verifier::visitGlobalIFunc`.
Should an object file be produced with an UND ifunc symbol in that case?
Wouldn't it be more correct to emit a plain old function declaration? (see
`llvm/test/Linker/ifunc.ll` for behavior of linking an ifunc on top of a
function declaration, should work correctly).
At the very least to alleviate the breakage I think we can just rip out the
`Assert(!Resolver->isDeclarationForLinker(), "...")` from the Verifier, but I
have a feeling that this is not the right long-term solution.
The cpu_specific/cpu_dispatch attributes are completely new to me, so bear with
me if I'm misunderstanding; wouldn't the following implementation both provide
the correct semantics and avoid an ifunc-with-an-undefined-resolver situation?
- The cpu_specific attribute emits
1. A Function Declaration with a computed name "x.ifunc"
2. A single Function with the cpu-specific body
3. Multiple GlobalAliases with computed named whose aliasee is the function
from 2)
- The cpu_dispatch attribute emits a strongly-defined non-interposable ifunc
with the same computed name "x.ifunc", and a hidden defined resolver. Both IR
linking and regular linking should resolve the plain
function-delcaration-references to the ifunc properly.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D112349/new/
https://reviews.llvm.org/D112349
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
