Note that currently types::IsCXX(InputType) is not used to determine -fsanitize flag values at all - we just look at the explicit flags (-frtti, -fno-rtti, -fapple-kext, -mkernel), and at the Triple (is it PS4?). Does it make sense to leave it that way? There is a special case: a) we're on PS4 b) we have a CXX input c) we've provided -fexceptions, but haven't provided -frtti In this case RTTI will still be implicitly enabled, but we would disable vptr sanitizer earlier at this point.
I'd say it's fine to sacrifice this special case :) (for that matter, to simplify things we could even make PS4 driver to issue a hard error if one is building CXX code with explicit -fexceptions but no explicit -frtti). That is, if we only look at Triple and input arguments, we can probably have ToolChain::getRTTIMode() much like we have ToolChain::getSanitizerArgs(), and use former in the latter. Does it all make sense? On Wed, Feb 11, 2015 at 6:08 PM, Filipe Cabecinhas < [email protected]> wrote: > This is getting a bit hard to reason about. > > Here are the pieces: > > - Default RTTI behavior for target (depends on other arguments like the > type of input file) > - RTTI related options (explicit) > - Sanitizer options (explicit (vptr) or implicit (undefined)) > > SanitizerArgs _wants_ to hide details like “which sanitizers exist/are > enabled”, which means it will have to sort out whether to warn/error or not > by itself (it needs to know if there's an explicit RTTI-related argument) . > > The RTTI-related code needs to know if C++ exceptions are on to decide if > it implicitly turns on RTTI or not (this implies knowing not just the > arguments, but also the input file). > > To decide whether we need additional args for RTTI or not, and which ones > to pass, we need to know the RTTI-related arguments passed and the input > type (actually, we need IsCXX(Input)). > > Easiest (kind of hacky) solution: Add enough arguments to getSanitizerArgs > and to the SanitizerArgs constructor to allow it to decide whether to > warn/error due to the vptr sanitizer (We'd parse the RTTI-related args, and > use those results (enabled/disabledexplicitly/disabledimplicitly + an > RTTI-related arg, if necessary) when calling getSanitizerArgs()). > > Easy (kind of hacky) solution (with a major drawback): Make it easy to, > via SanitizerArgs, add/remove sanitizers. It would be hard to know if the > vptr sanitizer was enabled explicitly or via -fsanitize=undefined, with > this solution (we'd have to re-parse everything, if we wanted to keep it > working that way). > > Non-hacky solutions: Sorry, couldn't think of one. Additional ones > included stashing stuff in the ToolChain object… It doesn't seem like it's > the proper thing to do. > > > http://reviews.llvm.org/D7525 > > EMAIL PREFERENCES > http://reviews.llvm.org/settings/panel/emailpreferences/ > > > -- Alexey Samsonov [email protected]
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
