Add support for building sanitizer-enabled jlls #255
Conversation
|
You mean for CI? Maybe just check that something like: triggers an asan/msan report? |
|
We should probably also teach the auditor to check for the presence of the asan/msan symbols in the executable to make sure that the thing that got compiled actually had the options set. |
src/Platforms.jl
Outdated
| @@ -146,3 +146,4 @@ const ARCHITECTURE_FLAGS = Dict( | |||
| ), | |||
| ) | |||
| march(p::AbstractPlatform; default=nothing) = get(tags(p), "march", default) | |||
| sanitizer(p::AbstractPlatform; default=nothing) = get(tags(p), "sanitizer", default) | |||
There was a problem hiding this comment.
Do we want to call this sanitizer or sanitize? The latter would match better with -fsanitize.
This adds support for automatically adding the appropriate `-fsanitize=` flags when the platform includes a `sanitizer` tag. This is particularly intended for msan, which requires that all .so's in the system are built using it, but could be useful for other sanitizers also. There's a couple annoyances. One is that we don't currently actually ship the sanitizer runtime libraries in our rootfs. Thus, if we want to start using this, we'd have to add a BuildDependency on LLVMCompilerRT_jll and manually copy the runtime libraries into place. Not the end of the world, but certainly a wart. The other issue is that `platform_matches` (which is defined in Base) of course currently ignores the `sanitizer` tag. In theory it is possible to add a custom compare strategy, but since we're specifying the target by triplet, we can't really add that. Easy enough to add manually here, but does make me wonder whether the custom compare strategies in Base actually fit the use case.
|
Renamed this to |
|
What's the benefit of having this as a platform tag? Is a library built with sanitizer incompatible with another library built without it? This is probably what you meant with
?
Would JuliaPackaging/Yggdrasil#1681 be a better long-term solution? |
Yes |
Yes - I haven't looked at that PR in detail, but presumably. |
In particular, julia would detect that it's built with sanitizers and append the platform tag itself. |
|
We should probably split out memory into |
This adds support for automatically adding the appropriate
-fsanitize=flags when the platform includes a
sanitizertag. This is particularlyintended for msan, which requires that all .so's in the system are built
using it, but could be useful for other sanitizers also.
There's a couple annoyances. One is that we don't currently actually ship
the sanitizer runtime libraries in our rootfs. Thus, if we want to start
using this, we'd have to add a BuildDependency on LLVMCompilerRT_jll and
manually copy the runtime libraries into place. Not the end of the world,
but certainly a wart.
The other issue is that
platforms_match(which is defined in Base) ofcourse currently ignores the
sanitizertag. In theory it is possibleto add a custom compare strategy, but since we're specifying the target
by triplet, we can't really add that. Easy enough to add manually here,
but does make me wonder whether the custom compare strategies in Base
actually fit the use case.