[PATCH] D69045: libhwasan interceptor ABI intercept longjmp/setjmp
Matthew Malcomson via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Thu May 14 04:15:33 PDT 2020
mmalcomson added a comment.
In D69045#2034976 <https://reviews.llvm.org/D69045#2034976>, @jdanek wrote:
> In D69045#2031667 <https://reviews.llvm.org/D69045#2031667>, @mmalcomson wrote:
>
> > (FWIW this particular `setjmp` can be intercepted in glibc 2.31 -- so hopefully as time goes on this will be less of a problem).
>
>
> I am the reporter of the linked GitHub issue. Are you saying that if I just built with glibc 2.31, without any change to clang, then I would not see this instance of the setjmp error?
>
> I believe I am on 2.31 already:
Oh that's interesting -- thanks for pointing it out.
Could you just double check `objdump` your libc -- if it still has a non-ptl symbol then it might be that there was something strange in my testing environment, and that in the wild this is usually non-interceptable.
Interestingly, the reason I added the `__libc_longjmp` interceptor (lines 282-287 in hwasan_interceptors.cpp in the patch above) was because I was seeing a jump buffer mismatch at pthread_exit in the exact opposite way of what you're seeing now (setjmp in libc_start_main was intercepted and longjmp in `unwind_stop` was not).
If you have the time, could you remove that interceptor, rebuild, and re-test in your environment? The output from that should give some useful information.
When I look into this I'll have to understand when glibc makes that symbol internal, and why my testing environment ended up with a dynamic one.
I still expect the best option would be to avoid non-hwasan jump buffers, as eugenis suggested, but it might be better to have avoid intercepting that symbol if that's what works without a fallback.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D69045/new/
https://reviews.llvm.org/D69045
More information about the llvm-commits
mailing list