[PATCH] Change how we deal with (implicit) -fno-rtti + -fsanitize=vptr

[Alexey Samsonov]

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 <
filcab+llvm.phabricator at gmail.com> 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
vonosmas at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20150211/d7628b9c/attachment.html>