-
Notifications
You must be signed in to change notification settings - Fork 78
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
AddressSanitizer support #3560
AddressSanitizer support #3560
Conversation
I'll look at the runtime changes. |
f996e58
to
fb6e329
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good. I have a few minor comments. I haven't read the test file in detail.
I'm pretty sure that the backend changes do not affect code generation when ASAN is disabled.
Someone more familiar with the runtime should review the relevant changes too.
ff9afd3
to
9f534d1
Compare
…Sanitizer integration
…ccesses by performing the load of `shadow_value` as part of the `cmp` instruction
… was invalid because its component registers had been clobbered
… convention used for the error-reporting stubs
…ield initialization stores
9f534d1
to
32aac6b
Compare
I've read the runtime parts. This is ok once the runtime5 implementation has been tested. |
@mshinwell Tested things with runtime5 internally; everything checks out |
This PR supersedes the earlier attempt at adding this functionality in #3033
Implement a new compiler configuration which integrates support for AddressSanitizer. When the compiler is configured with
--enable-address-sanitizer
the OCaml runtime is built against AddressSanitizer, and codegen is altered to instrument all loads and stores in accordance with the AddressSanitizer algorithm.The original implementation of this in #3033 ran into issues where certain files triggered pathological behavior in the register allocator when AddressSanitizer was enabled, resulting in the files taking up to several hours to compile where they had taken just seconds before. Having discussed this problem with @xclerc and @gretay-js and not finding an easy way to mitigate the issues in the register allocator, I've worked around this by completely reimplementing the AddressSanitizer instrumentation in a phase after register allocation. This avoids the pathological compile-times, but does come with some downsides, namely that the code is more complex and the runtime penalty is higher (internal testing on realistic benchmark I performed showed a 2.6x slowdown with my implementation in #3033, versus a 3x slowdown with this PR's implementation). There's definitely room for improvement in the runtime performance, but I'd rather get this out the door now since it works, and follow up with optimizations in future PRs.