davemgreen wrote: > The issue seems to be with pointers to functions, adding > > ``` > FDTy = getContext().getBaseElementType(FDTy); > return (FDTy->isPointerOrReferenceType() && > getContext().getTypeSize(FDTy) == 64 && > - !FDTy->getPointeeType().hasAddressSpace()) || > + !FDTy->getPointeeType().hasAddressSpace() && > + !FDTy->getPointeeType()->isFunctionType()) || > Self(Self, FDTy); > }); > }; > ``` > > to clang/lib/CodeGen/Targets/AArch64.cpp:512 makes the tests pass. > > The problematic type in our case seems to be > [abseil::FunctionRef](https://github.com/abseil/abseil-cpp/blob/master/absl/functional/function_ref.h#L85) > > Please let me know if this is sufficient, reducing internal test to a > standalone reproducer might take some time.
Hi - that might break some of my motivating examples (they were pointers passed in structs from lambda captures, I don't remember if the pointers were to functions or not, there were definitely a lot of function pointers flying around). In general I would have expected it to be better to avoid the ptrtoint->inttoptr when passed through a function argument though. Can we make it bail out for hwasan only with function pointers? I was trying with code like https://godbolt.org/z/xfW3vcjeo to see if I could hit the same issue (but imagine running on an AArch64 machine). Any ideas what it might take to trigger it (different option, certain code pattern?) https://github.com/llvm/llvm-project/pull/135064 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
