Commit Graph

17 Commits

Author SHA1 Message Date
Sunil Srivastava 5b04748157 Do not enable RTTI with -fexceptions, for PS4
NFC for targets other than PS4.

This patch is a change in behavior for PS4, in that PS4 will no longer enable
RTTI when -fexceptions is specified (RTTI and Exceptions are disabled by default
on PS4). RTTI will remain disabled except for types being thrown or caught.
Also, '-fexceptions -fno-rtti' (previously prohibited on PS4) is now accepted,
as it is for other targets.

This patch removes some PS4 specific code, making the code cleaner.

Also, in the test file rtti-options.cpp, PS4 tests where the behavior is the
same as the generic x86_64-linux are removed, making the test cleaner.

Differential Revision: https://reviews.llvm.org/D46982


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@332784 91177308-0d34-0410-b5e6-96231b3b80d8
2018-05-18 23:32:01 +00:00
Sunil Srivastava df58e5d6ad Fixed some rtti-options tests.
Certain tests in rtti-options.cpp are not really testing anything because they are testing for the absence of -frtti option to the cc1 process. Since the cc1 process does not take -frtti option, these tests are passing tautologically.

The RTTI mode is enabled by default in cc1, and -fno-rtti disables it. Therefore the correct way to check for enabling of RTTI is to check for the absence of -fno-rtti to cc1, and the correct way to check for disabling of RTTI is to check for the presence of -fno-rtti to cc1.

This patch fixes those tests.

Differential Revision: https://reviews.llvm.org/D46836


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@332384 91177308-0d34-0410-b5e6-96231b3b80d8
2018-05-15 18:28:42 +00:00
Alexander Kornienko b8b9458165 Fix typos in clang
Found via codespell -q 3 -I ../clang-whitelist.txt
Where whitelist consists of:

  archtype
  cas
  classs
  checkk
  compres
  definit
  frome
  iff
  inteval
  ith
  lod
  methode
  nd
  optin
  ot
  pres
  statics
  te
  thru

Patch by luzpaz! (This is a subset of D44188 that applies cleanly with a few
files that have dubious fixes reverted.)

Differential revision: https://reviews.llvm.org/D44188

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@329399 91177308-0d34-0410-b5e6-96231b3b80d8
2018-04-06 15:14:32 +00:00
Vedant Kumar 63a4e48486 [ubsan] Have -fsanitize=vptr emit a null check if -fsanitize=null isn't available
In r309007, I made -fsanitize=null a hard prerequisite for -fsanitize=vptr. I
did not see the need for the two checks to have separate null checking logic
for the same pointer. I expected the two checks to either always be enabled
together, or to be mutually compatible.

In the mailing list discussion re: r309007 it became clear that that isn't the
case. If a codebase is -fsanitize=vptr clean but not -fsanitize=null clean,
it's useful to have -fsanitize=vptr emit its own null check. That's what this
patch does: with it, -fsanitize=vptr can be used without -fsanitize=null.

Differential Revision: https://reviews.llvm.org/D36112

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@309846 91177308-0d34-0410-b5e6-96231b3b80d8
2017-08-02 18:10:31 +00:00
Vedant Kumar 5d285dac56 [ubsan] Null-check pointers in -fsanitize=vptr (PR33881)
The instrumentation generated by -fsanitize=vptr does not null check a
user pointer before loading from it. This causes crashes in the face of
UB member calls (this=nullptr), i.e it's causing user programs to crash
only after UBSan is turned on.

The fix is to make run-time null checking a prerequisite for enabling
-fsanitize=vptr, and to then teach UBSan to reuse these run-time null
checks to make -fsanitize=vptr safe.

Testing: check-clang, check-ubsan, a stage2 ubsan-enabled build

Differential Revision: https://reviews.llvm.org/D35735

https://bugs.llvm.org/show_bug.cgi?id=33881

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@309007 91177308-0d34-0410-b5e6-96231b3b80d8
2017-07-25 19:34:23 +00:00
Filipe Cabecinhas 22dbfd8117 PS4: Add tests for rtti/vptr-sanitizer interaction
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@250515 91177308-0d34-0410-b5e6-96231b3b80d8
2015-10-16 15:07:56 +00:00
Greg Bedwell fc7ebbf512 Revert "This patch adds missing pieces to clang, including the PS4 toolchain definition, added warnings, PS4 defaults, and Driver changes needed for our compiler."
This reverts commit r248546 to get our bot green again while we discuss the best way forward.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@248578 91177308-0d34-0410-b5e6-96231b3b80d8
2015-09-25 16:11:00 +00:00
Ekaterina Romanova 41604ec4c1 This patch adds missing pieces to clang, including the PS4 toolchain
definition, added warnings, PS4 defaults, and Driver changes needed for
our compiler.

A patch by Filipe Cabecinhas, Pierre Gousseau and Katya Romanova!

Differential Revision: http://reviews.llvm.org/D11279



git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@248546 91177308-0d34-0410-b5e6-96231b3b80d8
2015-09-24 22:06:52 +00:00
Alexey Samsonov bd98816515 [Sanitizers] Provide better diagnostic for sanitizers unsupported for target triple.
Introduce ToolChain::getSupportedSanitizers() that would return the set
of sanitizers available on given toolchain. By default, these are
sanitizers which don't necessarily require runtime support and are
not toolchain- or architecture-dependent.

Sanitizers (ASan, DFSan, TSan, MSan etc.) which cannot function
without runtime library are marked as supported only on platforms
for which we actually build these runtimes.

This would allow more fine-grained checks in the future: for instance,
we have to restrict availability of -fsanitize=vptr to Mac OS 10.9+
(PR23539).

Update test cases accrodingly: add tests for certain unsupported
configurations, remove test cases for -fsanitize=vptr + PS4
integration, as we don't build the runtime for PS4 at the moment.

This change was first submitted as r239953 and reverted in r239958.
The problem was and still is in Darwin toolchains, which get the
knowledge about target platform too late after initializaition, while
now we require this information when ToolChain::getSanitizerArgs() is
called. r240170 works around this issue.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@240179 91177308-0d34-0410-b5e6-96231b3b80d8
2015-06-19 21:36:47 +00:00
Alexey Samsonov 347af8f967 Revert "[Sanitizers] Provide better diagnostic for sanitizers unsupported for target triple."
This reverts commit r239953, while I'm investigating assertion
failure from http://lab.llvm.org:8080/green/job/clang-stage1-cmake-RA-incremental_check/9994/

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@239958 91177308-0d34-0410-b5e6-96231b3b80d8
2015-06-17 22:27:32 +00:00
Alexey Samsonov fb3d70bc0f [Sanitizers] Provide better diagnostic for sanitizers unsupported for target triple.
Summary:
Introduce ToolChain::getSupportedSanitizers() that would return the set
of sanitizers available on given toolchain. By default, these are
sanitizers which don't necessarily require runtime support (i.e.
set from -fsanitize=undefined-trap).

Sanitizers (ASan, DFSan, TSan, MSan etc.) which cannot function
without runtime library are marked as supported only on platforms
for which we actually build these runtimes.

This would allow more fine-grained checks in the future: for instance,
we have to restrict availability of -fsanitize=vptr to Mac OS 10.9+
(PR23539)

Update test cases accrodingly: add tests for certain unsupported
configurations, remove test cases for -fsanitize=vptr + PS4
integration, as we don't build the runtime for PS4 at the moment.

Test Plan: regression test suite

Reviewers: pcc

Subscribers: cfe-commits, filcab, eugenis, thakis, kubabrecka, emaste, rsmith

Differential Revision: http://reviews.llvm.org/D10467

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@239953 91177308-0d34-0410-b5e6-96231b3b80d8
2015-06-17 22:07:28 +00:00
Filipe Cabecinhas b690b4e662 Only add -fno-rtti if KernelOrKext or in C++ mode.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@232869 91177308-0d34-0410-b5e6-96231b3b80d8
2015-03-20 23:51:15 +00:00
Filipe Cabecinhas fbb819f555 Don't claim exception related arguments when looking at RTTIMode
Summary:
We were claiming the -f*exceptions arguments when looking for the
RTTIMode. This makes us not warn about unused arguments if compiling a C
file with -fcxx-exceptions.

This patch fixes it by not claiming the exception-related arguments at
that point.

Reviewers: rsmith, samsonov

Subscribers: cfe-commits

Differential Revision: http://reviews.llvm.org/D8507

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@232860 91177308-0d34-0410-b5e6-96231b3b80d8
2015-03-20 23:33:23 +00:00
Filipe Cabecinhas bdc1288ac8 Improve our handling of rtti/sanitize=vptr/sanitize=undefined
This patch removes the huge blob of code that is dealing with
rtti/exceptions/sanitizers and replaces it with:

A ToolChain function which, for a given set of Args, figures out if rtti
should be:
  - enabled
  - disabled implicitly
  - disabled explicitly

A change in the way SanitizerArgs figures out what sanitizers to enable
(or if it should error out, or warn);

And a check for exceptions/rtti interaction inside addExceptionArgs.

The RTTIMode algorithm is:
  - If -mkernel, -fapple-kext, or -fno-rtti are passed, rtti was disabled explicitly;
  - If -frtti was passed or we're not targetting the PS4, rtti is enabled;
  - If -fexceptions or -fcxx-exceptions was passed and we're targetting
    the PS4, rtti was enabled implicitly;
  - If we're targetting the PS4, rtti is disabled implicitly;
  - Otherwise, rtti is enabled;

Since the only flag needed to pass to -cc1 is -fno-rtti if we want to
disable it, there's no problem in saying rtti is enabled if we're
compiling C code, so we don't look at the input file type.

addExceptionArgs now looks at the RTTIMode and warns that rtti is being
enabled implicitly if targetting the PS4 and exceptions are on. It also
errors out if, targetting the PS4, -fno-rtti was passed, and exceptions
were turned on.

SanitizerArgs now errors out if rtti was disabled explicitly and the vptr
sanitizer was enabled implicitly, but just turns off vptr if rtti is
disabled but -fsanitize=undefined was passed.

Also fixed tests, removed duplicate name from addExceptionArgs comment,
and added one or two surrounding lines when running clang-format.
This changes test/Driver/fsanitize.c to make it not expect a warning when
passed -fsanitize=undefined -fno-rtti, but expect vptr to not be on.

Removed all users and definition of SanitizerArgs::sanitizesVptr().

Reviewers: samsonov

Subscribers: llvm-commits, samsonov, rsmith

Differential Revision: http://reviews.llvm.org/D7525

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@229801 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-19 01:04:49 +00:00
Filipe Cabecinhas e6fe5beb8f Tweak behavior due to -fexceptions, in C++ mode, imply -fcxx-exceptions
Added test

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@227695 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-31 23:05:51 +00:00
Filipe Cabecinhas 210d1346e2 Remove unneeded code
We don't really care about enabling RTTI with -fexceptions, only with
-fcxx-exceptions.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@227567 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-30 11:17:56 +00:00
Filipe Cabecinhas d816be98bb Add some more PS4 driver settings related to rtti and exceptions.
Summary:
The PS4 defaults to -fno-rtti, and has to have rtti enabled when enabling
exceptions.

This commit makes clang add the -fno-rtti by default on the PS4, unless
-frtti was passed in.

It also diagnoses misuses for the PS4:
- Exceptions need rtti. Warn and enable rtti if no rtti flag was passed,
  error if -fno-rtti was passed.

I also added a more general warning for when -fno-rtti is the default
(currently it's only on the PS4) and the vptr sanitizer is on.

Fixed a few tests, due to different flag order when passing cc1 arguments.

Reviewers: chandlerc

Subscribers: cfe-commits

Differential Revision: http://reviews.llvm.org/D7250

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@227518 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-29 23:56:43 +00:00