AAaron BallmanSpeculatively fix build bot
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
[compiler-rt] Rename lit.*.cfg.* -> lit.*.cfg.py.* These lit configuration files are really Python source code. Using the .py file extension helps editors and tools use the correct language mode. LLVM and Clang already use this convention for lit configuration, this change simply applies it to all of compiler-rt. Reviewers: vitalybuka, dberris Differential Revision: https://reviews.llvm.org/D63658 llvm-svn: 364591 | 7 年前 | |
Protection against stack-based memory corruption errors using SafeStack: compiler-rt runtime support library 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 | 11 年前 | |
Protection against stack-based memory corruption errors using SafeStack: compiler-rt runtime support library 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 | 11 年前 | |
[Safestack] Fix the canary test to catch the libc's message regarding stack smashing By default glibc writes its diagnostics directly to tty so the 2>&1 | redirection in the test doesn't catch the *** stack smashing detected *** message, which in turn breaks printing the lit's progress bar. By defining the LIBC_FATAL_STDERR_ environment variable we force glibc to direct diagnostic messages to stderr. Differential Revision: https://reviews.llvm.org/D32599 llvm-svn: 302628 | 9 年前 | |
Protection against stack-based memory corruption errors using SafeStack: compiler-rt runtime support library 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 | 11 年前 | |
[compiler-rt] Use ld64 flag -lto_library instead of DYLD_LIBRARY_PATH Makes bin/llvm-lit \ projects/compiler-rt/test/profile/Profile-arm64/instrprof-darwin-dead-strip.c pass on my machine. Without this change, ld64 complains that the bitcode was generated by LLVM 15 while the reader is 13.1 -- the version of Xcode on my machine. Looks like the DYLD_LIBRARY_PATH technique isn't working. -lto_library was added back in ld64-136, which was in Xcode 4.6, which was released over 10 years ago. So relying on it should be safe by now. Differential Revision: https://reviews.llvm.org/D124018 | 4 年前 | |
[compiler-rt] Rename lit.*.cfg.* -> lit.*.cfg.py.* These lit configuration files are really Python source code. Using the .py file extension helps editors and tools use the correct language mode. LLVM and Clang already use this convention for lit configuration, this change simply applies it to all of compiler-rt. Reviewers: vitalybuka, dberris Differential Revision: https://reviews.llvm.org/D63658 llvm-svn: 364591 | 7 年前 | |
Speculatively fix build bot This should fix the issue found by: https://lab.llvm.org/buildbot/#/builders/37/builds/12606 | 4 年前 | |
[C11/C2x] Change the behavior of the implicit function declaration warning 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 | 4 年前 | |
[C11/C2x] Change the behavior of the implicit function declaration warning 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 | 4 年前 | |
SafeStack: Use correct unsafe stack sizes Summary: When deallocating thread stacks, we use one thread's unsafe stack size to deallocate another thread's unsafe stack; however, the two sizes may differ. Record an unsafe stack's size in the thread stack linked list. Reviewers: pcc, eugenis Reviewed By: eugenis Subscribers: delcypher, llvm-commits, #sanitizers, kcc Differential Revision: https://reviews.llvm.org/D51016 llvm-svn: 340308 | 7 年前 | |
SafeStack: Disable Darwin support Summary: Darwin support does not appear to be used as evidenced by the fact that the pthread interceptors have never worked and there is no support for other common threading mechanisms like GCD. Reviewers: pcc, eugenis, kubamracek Reviewed By: pcc, kubamracek Subscribers: kubamracek, mgorny, delcypher, llvm-commits, #sanitizers, kcc Differential Revision: https://reviews.llvm.org/D50718 llvm-svn: 339719 | 7 年前 | |
Protection against stack-based memory corruption errors using SafeStack: compiler-rt runtime support library 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 | 11 年前 |