User Details
- User Since
- Dec 28 2012, 2:34 PM (535 w, 19 h)
Wed, Mar 22
Tue, Mar 21
Mon, Mar 20
Switch to template wrappers
Add #if !SANITIZER_APPLE
Fri, Mar 17
How do you usually build Scudo? When I run the unit tests I cross compile it for Android using llvm's gn build system. If you're building it as part of the Android platform, SCUDO_PREFIX will be defined to add a prefix of scudo_, so the alias in malloc.h wouldn't affect the definitions.
Bring back -Wl,-z,defs for Android
Thu, Mar 16
After an out of band discussion with Arthur, we figured out the root cause of his problem and I was able to reproduce. This fixes it for me.
Fix commit message
Thu, Mar 9
Tue, Mar 7
To be honest, I would rather we look at removing OptimizeGlobalAliases altogether. As I explained in D65118, these kinds of trivial alias "optimizations" on their own can be more harmful than helpful.
Mar 1 2023
Feb 27 2023
Can't the code in CodeGenModule::HasHiddenLTOVisibility be moved here instead of duplicating it?
Feb 22 2023
LGTM
Feb 21 2023
Passes shouldn't be replacing aliases with aliasees in general, see D66606. The right fix is to fix SCEV to not do that.
Feb 16 2023
Feb 9 2023
I've always considered that this should be fixed by extending the resolution-based LTO API to also include resolutions for comdats.
Jan 31 2023
LGTM
LGTM with nits
Jan 20 2023
Jan 19 2023
What do you think about making this apply not only to LTO but to other -r links as well? This would be useful for use cases like the internal symbolizer used by the sanitizers, which currently (ab)uses LTO for a similar effect. I was imagining that the user interface would be that we would make --version-script compatible with -r links, with the restriction being that it would not be possible to specify a symbol version (as this patch does).
LGTM
Dec 12 2022
A high level question is whether we want to base the cross-language encoding on Itanium at all. Itanium has concepts such as substitutions that will complicate the implementation in other languages. Encoding pointee types can also lead to complications in cross-language encodings.
Dec 5 2022
Can't this be implicit if LTO is being used?
LGTM
Nov 23 2022
Test case?
Nov 10 2022
LGTM
Nov 4 2022
Oct 19 2022
Will @browneee be a good candidate for Data Flow Sanitizer owner as well? Note that it's fine to have a library to have more than one owner in some cases.
Oct 13 2022
Does that DR apply retroactively to C++17? I get the impression that "Status: C++20" means that the issue was only fixed in C++20, which would make this well-formed with -std=c++17.
Oct 12 2022
Ping.
The sanitizer bot uses a 2-stage build so I'm not sure that it can be reproduced with a single CMake invocation. You should be able to reproduce on Linux with:
git clone https://github.com/llvm/llvm-zorg.git BUILDBOT_CLOBBER= BUILDBOT_REVISION=79ee0342dbf025bc70f237bdfe9ccb4e10a592ce llvm-zorg/zorg/buildbot/builders/sanitizers/buildbot_standard.sh
TSan builds are also broken with this change: https://lab.llvm.org/buildbot/#/builders/70/builds/28491
ld: error: undefined symbol: __tsan_func_entry >>> referenced by cxa_aux_runtime.cpp >>> libcxxabi/src/CMakeFiles/cxxabi_shared_objects.dir/cxa_aux_runtime.cpp.o:(__cxa_bad_cast) >>> referenced by cxa_aux_runtime.cpp >>> libcxxabi/src/CMakeFiles/cxxabi_shared_objects.dir/cxa_aux_runtime.cpp.o:(__cxa_bad_typeid) >>> referenced by cxa_aux_runtime.cpp >>> libcxxabi/src/CMakeFiles/cxxabi_shared_objects.dir/cxa_aux_runtime.cpp.o:(__cxa_throw_bad_array_new_length) >>> referenced 539 more times
(and more undefined symbols).
Oct 10 2022
Oct 6 2022
Oct 5 2022
In phabricator those markers just mean that you added indentation, not that you added a tab.
Sep 30 2022
Ping^2.
Sep 29 2022
Rebased this patch by first reverting the other ubsan patches
Looks like this never got approved and a different set of patches landed instead which didn't include shared library support :(
Jun 24 2022
Jun 23 2022
Comment
LGTM
Jun 15 2022
LGTM
Okay, it seems reasonable enough to have the [[clang::lto_visibility_public]] attribute override the --lto-whole-program-visibility flag.
I don't think I would expect the stage 2 runtimes to be built with a sanitizer even if use_asan is set. The sanitizer runtimes themselves don't support being built with sanitizers, and they might be compiled to depend on the builtins, which would create a circular dependency. So I think use_asan and such should only affect the stage 1 compiler. I think I would favor adding use_asan = false to the stage2_unix_toolchain template.
This diverges from the documented behavior of -lto-whole-program-visibility. The flag is meant to give all classes hidden LTO visibility, but now it only does that to some of them.