[llvm-dev] [compiler-rt][msan] msan tests failing on AArch64 (original) (raw)

Evgenii Stepanov via llvm-dev llvm-dev at lists.llvm.org
Fri Oct 26 10:08:08 PDT 2018

On Fri, Oct 26, 2018 at 7:12 AM David Greene <dag at cray.com> wrote:

Below are some of the failing addresses for two different tests. I've got about 20 or so tests that fail in this way. Thanks for looking into this!

Thanks! It looks like my proposed change should help then.

Is there a description somewhere of how these maps are determined?

Mappings need to

  1. Match MEM_TO_SHADOW and SHADOW_TO_ORIGIN definitions below. See CheckMemoryLayoutSanity.
  2. Cover all possible executable and library locations.

AArch64 mappings have an extra constraint: when trimmed to 39 or 42 bits VMA (by throwing out everything above that) they still need to make sense.

> I did not test this, but the following seems possible: > app-14 0x0AAA000000000 .. 0x0AAB000000000 > shadow-14 0x0AAC000000000 .. 0x0AAD000000000 > origin-14 0x0AAD000000000 .. 0x0AAE000000000 That would seem to agree with the data below, though I never saw 0xaaaf as a prefix in 10,000 runs. The highest I ever saw was 0xaaaea. -David

Test 1 0xaaad8cf2d490 0xaaabc698d490 0xaaab7aafd490 0xaaae3aa4d490 0xaaab6ec2d490 0xaaad64a1d490 0xaaac01f7d490 0xaaab057cd490 0xaaae0bb8d490 0xaaadb2fbd490 0xaaae8547d490 0xaaacc277d490 0xaaab704ed490 0xaaada62bd490 0xaaac4737d490 0xaaac76a7d490 0xaaadd1a4d490 0xaaaccbc2d490 0xaaae080dd490 0xaaadc414d490 0xaaad5dedd490 0xaaabb7f5d490 0xaaae4165d490 0xaaab9814d490 0xaaab94dad490 0xaaae124ed490 0xaaac6f82d490 0xaaab7c54d490 0xaaae3e32d490 0xaaae7a48d490 0xaaabf769d490 0xaaae6de9d490 0xaaad7eaed490 0xaaabe97ed490 0xaaabe58fd490 0xaaad363fd490 0xaaae3717d490 0xaaac13e8d490 0xaaad3c45d490 0xaaab4d37d490 0xaaaea00ed490 0xaaadcb95d490 0xaaae1888d490 0xaaab5530d490 0xaaac6a9ed490 0xaaacbe7fd490 0xaaabcc8cd490 0xaaac2701d490 0xaaad01afd490 0xaaad0dadd490 0xaaad7dead490 0xaaab7eb0d490 0xaaac8ed5d490 0xaaae8013d490 0xaaae3be8d490 0xaaacec0bd490 0xaaab6f3cd490 0xaaacbfa1d490 0xaaad8fead490 0xaaabc10bd490 0xaaad9a5ad490 0xaaabecc5d490 0xaaac0802d490 0xaaab00bcd490 0xaaae8b0ed490 0xaaacdc4dd490 0xaaae2cedd490 0xaaadcec2d490 0xaaae0ac6d490 0xaaace326d490 0xaaae39a8d490 0xaaadb117d490 0xaaac32fad490 0xaaabb1c9d490 0xaaaccd47d490 0xaaad17f0d490 0xaaad252fd490 0xaaad7183d490 0xaaab1010d490 0xaaac75ffd490 0xaaae45cbd490 0xaaab9b7cd490 0xaaae41fad490 0xaaadb898d490 0xaaab0589d490 0xaaab9990d490 0xaaac4babd490 0xaaab19a4d490 0xaaae0d16d490 0xaaab6f92d490 0xaaadb5d1d490 Test 2 0xaaae5938d4b0 0xaaab5134d4b0 0xaaad3461d4b0 0xaaabbe42d4b0 0xaaae3d0dd4b0 0xaaade03ad4b0 0xaaac7f14d4b0 0xaaabd7f0d4b0 0xaaae553ed4b0 0xaaac04d7d4b0 0xaaad5b02d4b0 0xaaaea137d4b0 0xaaabdb2cd4b0 0xaaabf431d4b0 0xaaac933ad4b0 0xaaab5564d4b0 0xaaae84c5d4b0 0xaaac2af5d4b0 0xaaacf5ecd4b0 0xaaad7d2bd4b0 0xaaaba9e6d4b0 0xaaae97cfd4b0 0xaaab21d5d4b0 0xaaad6c3bd4b0 0xaaac01f9d4b0 0xaaae7353d4b0 0xaaabb5c7d4b0 0xaaabd392d4b0 0xaaab0787d4b0 0xaaacdbd4d4b0 0xaaabc8d2d4b0 0xaaab6fafd4b0 0xaaad8ef8d4b0 0xaaab5bccd4b0 0xaaae78f5d4b0 0xaaada9b0d4b0 0xaaacc4afd4b0 0xaaab68dad4b0 0xaaac9fd7d4b0 0xaaab96f6d4b0 0xaaac12a9d4b0 0xaaac2c4bd4b0 0xaaae8aa8d4b0 0xaaac7d59d4b0 0xaaab8f07d4b0 0xaaad17dcd4b0 0xaaabed8dd4b0 0xaaae2a43d4b0 0xaaac133dd4b0 0xaaac5aa1d4b0 0xaaae0e3fd4b0 0xaaac04f5d4b0 0xaaac2861d4b0 0xaaae73ffd4b0 0xaaab6d75d4b0 0xaaae2e1ad4b0 0xaaab7ccbd4b0 0xaaad15a0d4b0 0xaaacaba8d4b0 0xaaab9004d4b0 0xaaae57e6d4b0 0xaaad7265d4b0 0xaaabcc47d4b0 0xaaac8b20d4b0 0xaaadf688d4b0 0xaaad361ed4b0 0xaaabcb51d4b0 0xaaab2894d4b0 0xaaab4494d4b0 0xaaae92e5d4b0 0xaaab8093d4b0 0xaaade01cd4b0 0xaaac9051d4b0 0xaaac3371d4b0 0xaaab94fed4b0 0xaaad70cbd4b0 0xaaacdf29d4b0 0xaaae5b0bd4b0 0xaaac6e4fd4b0 0xaaac9ec5d4b0 0xaaad4e10d4b0 0xaaac4a17d4b0 0xaaae46b5d4b0 0xaaac95acd4b0 0xaaac86cbd4b0 0xaaab57e2d4b0 Evgenii Stepanov via llvm-dev <llvm-dev at lists.llvm.org> writes: > Could you run the binary a few times and collect different code > addresses it complains about? > Could be a change in ASLR randomness. > It looks like the ranges in aarch64 shadow mapping are unnecessarily > restrictive. > I did not test this, but the following seems possible: > app-14 0x0AAA000000000 .. 0x0AAB000000000 > shadow-14 0x0AAC000000000 .. 0x0AAD000000000 > origin-14 0x0AAD000000000 .. 0x0AAE000000000 > > On Thu, Oct 25, 2018 at 6:42 AM David Greene via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > Adhemerval Zanella via llvm-dev <llvm-dev at lists.llvm.org> writes: > > > This seems to be printed by InitShadow and it is an > initialization routine > > which runs on all msan enabled binaries. The only issue I think > is runtime _> > is set msantrackorigins by -msan-track-origins=1 option and > unfortunately > > it does not seem to be stressed in any testcase. Is it the case > on this binary > > you are testing? > > These are existing tests in the repository. I don't see > -msan-track-origins set in the RUN lines so that can't be the only > thing > that enables this message. > > -David _> ________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > _> ________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20181026/5c020b44/attachment.html>

More information about the llvm-dev mailing list