> That's an overkill. Doing a check in REAL() will require disruptive changes
> and may negatively affect performance, while if REAL(foo) is NULL when it's
> called we'll get a SEGV with a descriptive stack strace.
Np, as long as we give a hint about this on wiki.
>> My proposal was to add ctor
>> directly to ASan runtime.
>
> Do you have a test case where it would help?
Here is one example which currently works by pure luck:
INTERCEPTOR(int, sigaction, int signum, const struct sigaction *act,
struct sigaction *oldact) {
if (!AsanInterceptsSignal(signum) ||
common_flags()->allow_user_segv_handler) {
return REAL(sigaction)(signum, act, oldact);
}
Note the lack of ENSURE_ASAN_INITED - this may easily result in call
to NULL function if we preload libasan to unsanitized executable which
calls signal() at start of main. The only reason why it manages to
work is because libstdc++ calls __cxa_atexit at start and this calls
ENSURE_ASAN_INITED. But relying on __cxa_atexit is surely messy.
Having an __attribute__((constructor)) for __asan_init would clean all
this stuff up.
> Ah. Now I remember this. Yes, we may want to improve the warning to handle
> the PLT case.
> No idea how, and the change would need to be testable in LLVM tree, which in
> turn requires that
> we build and support asan-dso in llvm tree as a non-default alternative to
> the static run-time.
> We may eventually get to it, but no promises.
Well, I'll keep hoping then)
-Y
--
You received this message because you are subscribed to the Google Groups
"address-sanitizer" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
