efriedma-quic wrote:
Oh, hmm, I see.
Maybe the right strategy here is to delay attaching the resolver to the ifunc
until the end of the translation unit, when we know the definition is already
emitted. That way, it should already have the right attributes. (We already
do some delayed
aokblast wrote:
The problem happens because ifunc can refer resolver that havn't been defined
before ifunc attribute. But LLVM Function only add attribute when it
constructed first time. So there are two possible path:
In the under case, no_sanitize cannot be add because it happens at
efriedma-quic wrote:
Probably you want a dedicated codepath for computing the right kcfi type for
resolvers.
https://github.com/llvm/llvm-project/pull/96400
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
aokblast wrote:
I think it is not the correct way to fix this issue. GD is type for ifunc not
for resolver. So the CI brokes if we do things like this.
https://github.com/llvm/llvm-project/pull/96400
___
cfe-commits mailing list
efriedma-quic wrote:
Please fix buildbot failure (it looks like clang/test/CodeGen/ifunc.c is
failing).
https://github.com/llvm/llvm-project/pull/96400
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
llvmbot wrote:
@llvm/pr-subscribers-clang
Author: None (aokblast)
Changes
In FreeBSD, we use ifunc to select best performance function in load time.
However, the resolver is also a function itself but not been tagged kcfi by
clang. The problems is caused by
```
if (D)
https://github.com/aokblast created
https://github.com/llvm/llvm-project/pull/96400
In FreeBSD, we use ifunc to select best performance function in load time.
However, the resolver is also a function itself but not been tagged kcfi by
clang. The problems is caused by
```
if (D)
