| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
[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 | 6 年前 | |
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 | 10 年前 | |
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 | 10 年前 | |
[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 | 8 年前 | |
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 | 10 年前 | |
[NFC][Py Reformat] Reformat python files in the rest of the dirs This is an ongoing series of commits that are reformatting our Python code. This catches the last of the python files to reformat. Since they where so few I bunched them together. Reformatting is done with black. If you end up having problems merging this commit because you have made changes to a python file, the best way to handle that is to run git checkout --ours <yourfile> and then reformat it with black. If you run into any problems, post to discourse about it and we will try to help. RFC Thread below: https://discourse.llvm.org/t/rfc-document-and-standardize-python-code-style Reviewed By: jhenderson, #libc, Mordante, sivachandra Differential Revision: https://reviews.llvm.org/D150784 | 3 年前 | |
[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 | 6 年前 | |
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 | 10 年前 |
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 6 年前 | ||
| 10 年前 | ||
| 10 年前 | ||
| 8 年前 | ||
| 10 年前 | ||
| 3 年前 | ||
| 6 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 7 年前 | ||
| 7 年前 | ||
| 10 年前 |