[PATCH] D112349: [Verifier] Add verification logic for GlobalIFuncs

Itay Bookstein via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Nov 2 15:34:32 PDT 2021


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



More information about the llvm-commits mailing list