Displaying 6 results from an estimated 6 matches for "sspstrong".
2012 Oct 02
5
[LLVMdev] [PROPOSAL] Adding support for -fstack-protector-strong
...ose any stack
address. In fact, the GCC patch does not implement this either, see [2].
Implementation
--------------
The bulk of the work required for stack-protector-strong is already implemented
for the existing stack-protector support.
The proposed work is:
1 Adding a new IR attribute "sspstrong":
ssp - SSP on, use basic heuristic
sspstrong - SSP on, use strong heuristic
sspreq - SSP on, required for function
- Note, I am proposing the IR attribute because it fits nicely into the
existing structure. An alternative choice would be to add a new CodeGen...
2012 Oct 02
0
[LLVMdev] [PROPOSAL] Adding support for -fstack-protector-strong
...C patch does not implement this either, see [2].
>
>
> Implementation
> --------------
> The bulk of the work required for stack-protector-strong is already implemented
> for the existing stack-protector support.
> The proposed work is:
> 1 Adding a new IR attribute "sspstrong":
> ssp - SSP on, use basic heuristic
> sspstrong - SSP on, use strong heuristic
> sspreq - SSP on, required for function
> - Note, I am proposing the IR attribute because it fits nicely into the
> existing structure. An alternative choice wo...
2019 Aug 10
2
[RFC] Stack overflow and optimizations
...esource is available.
This gives LLVM the freedom to grow or shrink stack frames. But this dos *not*
mean that stack overflows are UB!
> Also, we optimize the function
> ```
> void overflow() {
> overflow();
> }
> ```
> to
> ```
> ; Function Attrs: nounwind readnone sspstrong uwtable
> define dso_local void @"?overflow@@YAXXZ"() local_unnamed_addr #0 {
> entry:
> ret void
> }
> ```
This looks like an instance of the C++ forward progress assumption?
(C AFAIK only has that assumption for [some] loops, not recursive functions, so
arguably this i...
2019 Aug 02
2
[RFC] Stack overflow and optimizations
During the review of https://reviews.llvm.org/D59978 we got to the
question whether we can optimize based on the assumption that stack
overflow is undefined behavior. While I think it is according to the
C++ standard, Windows Structured Exception Handling and signal
handlers might allow programs to recover/exit gracefully.
Concretely, the patch D59978 wants add the noreturn attribute to
functions
2019 Jul 23
2
Accessing global variables arrays result in inlined getelementptrs
...mentptr instructions seem to be somehow inlined.
For example:
int a[256];
int main() {
a[0] = 1;
}
gives as a result the following IR code (with clang+llvm 8, without any
flag).
@a = common dso_local global [256 x i32] zeroinitializer, align 16
; Function Attrs: noinline nounwind optnone sspstrong uwtable
define dso_local i32 @main() #0 {
store i32 1, i32* getelementptr inbounds ([256 x i32], [256 x i32]*
@a, i64 0, i64 0), align 16
ret i32 0
}
Hence two questions.
- What is the main reason behind this behavior?
- Is there a way to disable it (ideally while preserving optimisations...
2014 Nov 03
8
[LLVMdev] [PATCH] Protection against stack-based memory corruption errors using SafeStack
...54) and compiler-rt
(r220991). The same changes are also available on
https://github.com/cpi-llvm <http://github.com/cpi-llvm> in the
safestack-r221153 branches of corresponding repositories. The patches make
the following changes:
-- Add the safestack function attribute, similar to the ssp, sspstrong and
sspreq attributes.
-- Add the SafeStack instrumentation pass that applies the safe stack to
all functions that have the safestack attribute. This pass moves all unsafe
local variables to the unsafe stack with a separate stack pointer, whereas
all safe variables remain on the regular stack that...