On Wed, Feb 20, 2019 at 2:12 PM Kostya Serebryany <kcc@xxxxxxxxxx> wrote: > > On Wed, Feb 20, 2019 at 1:40 PM Arnd Bergmann <arnd@xxxxxxxx> wrote: > > > > On Wed, Feb 20, 2019 at 10:13 PM Arnd Bergmann <arnd@xxxxxxxx> wrote: > > > > > > In the example in https://bugs.llvm.org/show_bug.cgi?id=38809#c12 > > > (https://godbolt.org/z/ylsGSQ) there is no inlining, yet clang uses > > > over ten times as much stack space as gcc, for reasons I still > > > can't explain. My assumption right now is that the underlying bug > > > causes most of the problems with excessive stack usage in > > > allmodconfig kernels. > > > > Here is an even more minimal example: > > > > struct s { int i[5]; } f(void); > > void g(void) { f(); f();} > > On this example I can see some stupidity that clang/asan is doing. > Let me try fixing it and see if it helps bigger cases. > Thanks for reducing the case! > > This is the input we get in the asan instrumentation: > > ; Function Attrs: noinline nounwind optnone sanitize_address uwtable > define dso_local void @g() #0 { > entry: > %tmp = alloca %struct.s, align 4 <<<<<<<<<<<<<<<<<<<<<<< > %tmp1 = alloca %struct.s, align 4 > %0 = bitcast %struct.s* %tmp to i8* > call void @llvm.lifetime.start.p0i8(i64 20, i8* %0) #3 > call void @f(%struct.s* sret %tmp) > %1 = bitcast %struct.s* %tmp to i8* <<<<<<<<<<<<<<<<<<<<< > call void @llvm.lifetime.end.p0i8(i64 20, i8* %1) #3 > %2 = bitcast %struct.s* %tmp1 to i8* > call void @llvm.lifetime.start.p0i8(i64 20, i8* %2) #3 <<<<<<<<<<<<< > call void @f(%struct.s* sret %tmp1) > %3 = bitcast %struct.s* %tmp1 to i8* > call void @llvm.lifetime.end.p0i8(i64 20, i8* %3) #3 > ret void > } Err.. taking my words back. These allocas *are* used other then in lifetime markers, since they are passed to f() as 'sret'. And we can not drop instrumentation for such allocas. Example: static volatile int zero = 0; typedef struct { int ar[5]; } S; S foo() { S s; s.ar[zero + 6] = 42; return s; } int main(int argc, char **argv) { S s = foo(); return s.ar[argc]; } % clang -g -O1 -fsanitize=address sret.c && ./a.out ==5822==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffcad027f78 at pc 0x0000004f878d bp 0x7ffcad027f20 sp 0x7ffcad027f18 WRITE of size 4 at 0x7ffcad027f78 thread T0 #0 0x4f878c in foo sret.c:7:18 #1 0x4f8838 in main sret.c:11:9 Address 0x7ffcad027f78 is located in stack of thread T0 at offset 56 in frame #0 0x4f879f in main sret.c:10 This frame has 1 object(s): [32, 52) 's' (line 11) <== Memory access at offset 56 overflows this variable Here we have a struct return that needs to be instrumented inside main so that a buffer overflow in foo() is detected. Now, I am also not confident that the reduced case reflects the real problem. --kcc > > the stack variables are not *really* used, but since they are "used" > inside the lifetime markers they are not eliminated by asan, > and so asan instruments them, after which no one can remove them any more... > > > > > > > > https://godbolt.org/z/d_KWkh > > > > It's clear that clang does /something/ here when asan-stack=1 is > > set, but I fail to see what it is, or why that is necessary. > > > > The output of clang with asan-stack=0 is the expected > > code, and basically identical to what gcc produces with or > > without asan-stack. > > > > Arnd