C89 had a questionable feature where the compiler would implicitly
declare a function that the user called but was never previously
declared. The resulting function would be globally declared as
extern int func(); -- a function without a prototype which accepts zero
or more arguments.
C99 removed support for this questionable feature due to severe
security concerns. However, there was no deprecation period; C89 had
the feature, C99 didn't. So Clang (and GCC) both supported the
functionality as an extension in C99 and later modes.
C2x no longer supports that function signature as it now requires all
functions to have a prototype, and given the known security issues with
the feature, continuing to support it as an extension is not tenable.
This patch changes the diagnostic behavior for the
-Wimplicit-function-declaration warning group depending on the language
mode in effect. We continue to warn by default in C89 mode (due to the
feature being dangerous to use). However, because this feature will not
be supported in C2x mode, we've diagnosed it as being invalid for so
long, the security concerns with the feature, and the trivial
workaround for users (declare the function), we now default the
extension warning to an error in C99-C17 mode. This still gives users
an easy workaround if they are extensively using the extension in those
modes (they can disable the warning or use -Wno-error to downgrade the
error), but the new diagnostic makes it more clear that this feature is
not supported and should be avoided. In C2x mode, we no longer allow an
implicit function to be defined and treat the situation the same as any
other lookup failure.
Differential Revision: https://reviews.llvm.org/D122983
Summary:
pthread_join() can return before a thread finishes exit()ing in the
kernel and a subsequent tgkill() can report the thread still alive.
Update the pthread-cleanup.c test to sleep and retry if it hits this
possible flake.
Thanks to Jeremy Morse for reporting.
Reviewers: jmorse, eugenis, vitalybuka
Reviewed By: jmorse, vitalybuka
Subscribers: delcypher, jfb, llvm-commits, #sanitizers, kcc
Differential Revision: https://reviews.llvm.org/D52330
llvm-svn: 342763
This relands commit r339405 (reverted in commit r339408.) The original
revert was due to tests failing on a darwin buildbot; however, after
looking at the affected code more I realized that the Darwin safestack
support has always been broken and disabled it in r339719. This relands
the original commit.
llvm-svn: 339723
This reverts commit r339405, it's failing on Darwin buildbots because
it doesn't seem to have a tgkill/thr_kill2 interface. It has a
__pthread_kill() syscall, but that relies on having a handle to the
thread's port which is not equivalent to it's tid.
llvm-svn: 339408
Summary:
glibc can call SafeStack instrumented code even after the last pthread
data destructor has run. Delay cleaning-up unsafe stacks for threads
until the thread is dead by having future threads clean-up prior threads
stacks.
Reviewers: pcc, eugenis
Reviewed By: eugenis
Subscribers: cryptoad, eugenis, kubamracek, delcypher, llvm-commits, #sanitizers, kcc
Differential Revision: https://reviews.llvm.org/D50406
llvm-svn: 339405
This patch adds runtime support for the Safe Stack protection to compiler-rt
(see http://reviews.llvm.org/D6094 for the detailed description of the
Safe Stack).
This patch is our implementation of the safe stack on top of compiler-rt. The
patch adds basic runtime support for the safe stack to compiler-rt that
manages unsafe stack allocation/deallocation for each thread.
Original patch by Volodymyr Kuznetsov and others at the Dependable Systems
Lab at EPFL; updates and upstreaming by myself.
Differential Revision: http://reviews.llvm.org/D6096
llvm-svn: 239763
Aaron Ballman