This prevents link errors when operators new/delete are overridden by application.
Diff Detail
Event Timeline
I am reluctant to add any new flags if there is any possibility to avoid doing so.
Is there any other solution for your problem?
E.g. you can disable the override of new/delete when building with asan.
Unfortunately, this is not an option. I have very custom heap implementation (in fact multiple heap types sharing contiguous memory block), so ASAN heap can't be a drop-in replacement. I'm using manual poisoning and it works pretty well, but have to disable C++ runtime each time I build with ASAN.
Another problem is ASANing libcxx tests because of overridden new operator (count_new.hpp). I think it makes sense to have counterpart for -fsanitize-link-c++-runtime, no?
It may appear to work well, but still be less powerful than what ASAN does for the regular malloc.
Do you have readzones? quarantine? [de]allocation stack traces?
but have to disable C++ runtime each time I build with ASAN.
How do you do this now?
Another problem is ASANing libcxx tests because of overridden new operator (count_new.hpp). I think it makes sense to have counterpart for -fsanitize-link-c++-runtime, no?
Is that related to https://github.com/google/sanitizers/issues/295 ?
weak new/delete may solve this particular problem, but may cause confusion to lots of other users,
e.g. in cases when a user has overridden new/delete for non-essential reasons (e.g. debuging) and can disable the overrides in asan mode.
With weak symbols such a user will never know they have a problem.
Our malloc definition is weak already, this will only change new/delete to match.
This also makes the behaviour of static runtime consistent with the one of dynamic runtime where we can not prevent user from overloading operator new/delete.
How do you do this now?
Sometimes with this patch, sometimes simply issuing linker command line manually
Is that related to https://github.com/google/sanitizers/issues/295 ?
I don't think so. I'm experiencing link error, not C++ standard discrepancy.
Would turning asan operator new/delete into weak symbols help?
The new operator is already a weak symbol in libcxx, so it looks like an ODR violation, doesn't it?
Would turning asan operator new/delete into weak symbols help?
The new operator is already a weak symbol in libcxx, so it looks like an ODR violation, doesn't it?
I don't think so. It's just symbol interposition. Every module in the process gets the same definition.
don't think so. It's just symbol interposition. Every module in the process gets the same definition.
If I have two weak symbols in lib1.a and lib2.a and don't define strong one, which one will be chosen at link time?
Linux linkers won't include a member of an archive only because it resolves a weak symbol, so in your example the answer is none.
ASan uses -Wl,-whole-archive to pull all its members, this will resolve operator new to ASan definition unless there is another definition in the main executable. In general, the first one in the order of command line arguments will be used.
ASan uses -Wl,-whole-archive to pull all its members
Yep, I forgot about this. Looks like weak new/delete will do the job then.