This is an archive of the discontinued LLVM Phabricator instance.

[msan] Poison the entire stack frame with one memset
Needs ReviewPublic

Authored by eugenis on Feb 16 2015, 7:17 AM.

Details

Reviewers
kcc
samsonov
Summary

Fix current ineffective MSan function prologue by lumping all locals into a single alloca (a-la ASan, but without redzones) and poisoning it with a single memset call.

This sounds like it could share some code with ASan, but there are way too many little differencies between two tools, so I copied ASan implementation into MSan and greatly simplified it.

Diff Detail

Repository
rL LLVM

Event Timeline

eugenis updated this revision to Diff 20032.Feb 16 2015, 7:17 AM
eugenis retitled this revision from to [msan] Poison the entire stack frame with one memset.
eugenis updated this object.
eugenis edited the test plan for this revision. (Show Details)
eugenis added reviewers: samsonov, kcc.
eugenis set the repository for this revision to rL LLVM.
eugenis added a subscriber: Unknown Object (MLST).

This is a partial fix for
https://code.google.com/p/memory-sanitizer/issues/detail?id=74

Origin-related issues in function prologue will be fixed in a follow-up change.

Benchmarks show marginal perf and code size improvement (~2% on a few benchmarks, nothing on most).
And a significant increase in stack frame size. Must have something to do with stack reuse (did not know llvm does that).

Ex., current instrumentation poisons the same stack location several times in a row. I guess it is being reused for multiple local variable.

28e3f8:       49 bd f8 ff ff ff ff    movabs $0xffffbffffffffff8,%r13
28e445:       4c 21 eb                and    %r13,%rbx
28e490:       48 c7 43 18 ff ff ff    movq   $0xffffffffffffffff,0x18(%rbx)
28e497:       ff
28e498:       48 c7 43 10 ff ff ff    movq   $0xffffffffffffffff,0x10(%rbx)
28e49f:       ff
28e4a0:       48 c7 43 08 ff ff ff    movq   $0xffffffffffffffff,0x8(%rbx)
28e4a7:       ff
28e4a8:       48 c7 03 ff ff ff ff    movq   $0xffffffffffffffff,(%rbx)
28e4af:       48 c7 43 18 ff ff ff    movq   $0xffffffffffffffff,0x18(%rbx)
28e4b6:       ff
28e4b7:       48 c7 43 10 ff ff ff    movq   $0xffffffffffffffff,0x10(%rbx)
28e4be:       ff
28e4bf:       48 c7 43 08 ff ff ff    movq   $0xffffffffffffffff,0x8(%rbx)
28e4c6:       ff
28e4c7:       48 c7 03 ff ff ff ff    movq   $0xffffffffffffffff,(%rbx)
28e4ce:       48 c7 43 18 ff ff ff    movq   $0xffffffffffffffff,0x18(%rbx)
28e4d5:       ff
28e4d6:       48 c7 43 10 ff ff ff    movq   $0xffffffffffffffff,0x10(%rbx)
28e4dd:       ff
28e4de:       48 c7 43 08 ff ff ff    movq   $0xffffffffffffffff,0x8(%rbx)
28e4e5:       ff
28e4e6:       48 c7 03 ff ff ff ff    movq   $0xffffffffffffffff,(%rbx)

This function has stack frame of 0x198 with the current instrumentation and 0x388 with new one, which suppresses stack reuse (0x300 out of 0x388 is poisoned, the rest must be spill slots).

samsonov edited edge metadata.Feb 17 2015, 4:46 PM

You probably know better after examining the code, but it would still be very sad if we had to copy the logic. I will be able to review it later this week.

Please hold off the review. I don't really like the stack growth (note that this is an issue for ASan, as well!), I'm going to try a different approach.

kcc edited edge metadata.Feb 18 2015, 10:22 AM

I don't think this is an issue with asan as it deliberately disables stack reuse to find stack-use-after-{return,scope}