This is an archive of the discontinued LLVM Phabricator instance.

[AddressSanitizer] Add flag to disable linking with CXX runtime
Needs ReviewPublic

Authored by evgeny777 on Nov 26 2018, 9:10 AM.

Details

Summary

This prevents link errors when operators new/delete are overridden by application.

Diff Detail

Event Timeline

evgeny777 created this revision.Nov 26 2018, 9:10 AM
kcc added a comment.Nov 28 2018, 11:56 AM

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.

evgeny777 added a comment.EditedNov 28 2018, 7:53 PM

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?

kcc added a comment.Nov 29 2018, 8:25 AM

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,

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 ?

Would turning asan operator new/delete into weak symbols help?

kcc added a comment.Nov 29 2018, 10:44 AM

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.

evgeny777 added a comment.EditedDec 2 2018, 1:02 AM

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.