<div dir="ltr"><div dir="ltr"><div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Fri, Oct 26, 2018 at 7:12 AM David Greene <<a href="mailto:dag@cray.com">dag@cray.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Below are some of the failing addresses for two different tests. I've<br>
got about 20 or so tests that fail in this way. Thanks for looking into<br>
this!<br></blockquote><div><br></div><div>Thanks! It looks like my proposed change should help then.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Is there a description somewhere of how these maps are determined?<br></blockquote><div><br></div><div>Mappings need to</div><div>1. Match MEM_TO_SHADOW and SHADOW_TO_ORIGIN definitions below. See CheckMemoryLayoutSanity.</div><div>2. Cover all possible executable and library locations.</div><div><br></div><div>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.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> I did not test this, but the following seems possible:<br>
> app-14 0x0AAA000000000 .. 0x0AAB000000000<br>
> shadow-14 0x0AAC000000000 .. 0x0AAD000000000<br>
> origin-14 0x0AAD000000000 .. 0x0AAE000000000<br>
<br>
That would seem to agree with the data below, though I never saw 0xaaaf<br>
as a prefix in 10,000 runs. The highest I ever saw was 0xaaaea.<br>
<br>
-David<br>
<br>
<br>
Test 1<br>
0xaaad8cf2d490<br>
0xaaabc698d490<br>
0xaaab7aafd490<br>
0xaaae3aa4d490<br>
0xaaab6ec2d490<br>
0xaaad64a1d490<br>
0xaaac01f7d490<br>
0xaaab057cd490<br>
0xaaae0bb8d490<br>
0xaaadb2fbd490<br>
0xaaae8547d490<br>
0xaaacc277d490<br>
0xaaab704ed490<br>
0xaaada62bd490<br>
0xaaac4737d490<br>
0xaaac76a7d490<br>
0xaaadd1a4d490<br>
0xaaaccbc2d490<br>
0xaaae080dd490<br>
0xaaadc414d490<br>
0xaaad5dedd490<br>
0xaaabb7f5d490<br>
0xaaae4165d490<br>
0xaaab9814d490<br>
0xaaab94dad490<br>
0xaaae124ed490<br>
0xaaac6f82d490<br>
0xaaab7c54d490<br>
0xaaae3e32d490<br>
0xaaae7a48d490<br>
0xaaabf769d490<br>
0xaaae6de9d490<br>
0xaaad7eaed490<br>
0xaaabe97ed490<br>
0xaaabe58fd490<br>
0xaaad363fd490<br>
0xaaae3717d490<br>
0xaaac13e8d490<br>
0xaaad3c45d490<br>
0xaaab4d37d490<br>
0xaaaea00ed490<br>
0xaaadcb95d490<br>
0xaaae1888d490<br>
0xaaab5530d490<br>
0xaaac6a9ed490<br>
0xaaacbe7fd490<br>
0xaaabcc8cd490<br>
0xaaac2701d490<br>
0xaaad01afd490<br>
0xaaad0dadd490<br>
0xaaad7dead490<br>
0xaaab7eb0d490<br>
0xaaac8ed5d490<br>
0xaaae8013d490<br>
0xaaae3be8d490<br>
0xaaacec0bd490<br>
0xaaab6f3cd490<br>
0xaaacbfa1d490<br>
0xaaad8fead490<br>
0xaaabc10bd490<br>
0xaaad9a5ad490<br>
0xaaabecc5d490<br>
0xaaac0802d490<br>
0xaaab00bcd490<br>
0xaaae8b0ed490<br>
0xaaacdc4dd490<br>
0xaaae2cedd490<br>
0xaaadcec2d490<br>
0xaaae0ac6d490<br>
0xaaace326d490<br>
0xaaae39a8d490<br>
0xaaadb117d490<br>
0xaaac32fad490<br>
0xaaabb1c9d490<br>
0xaaaccd47d490<br>
0xaaad17f0d490<br>
0xaaad252fd490<br>
0xaaad7183d490<br>
0xaaab1010d490<br>
0xaaac75ffd490<br>
0xaaae45cbd490<br>
0xaaab9b7cd490<br>
0xaaae41fad490<br>
0xaaadb898d490<br>
0xaaab0589d490<br>
0xaaab9990d490<br>
0xaaac4babd490<br>
0xaaab19a4d490<br>
0xaaae0d16d490<br>
0xaaab6f92d490<br>
0xaaadb5d1d490<br>
<br>
Test 2<br>
0xaaae5938d4b0<br>
0xaaab5134d4b0<br>
0xaaad3461d4b0<br>
0xaaabbe42d4b0<br>
0xaaae3d0dd4b0<br>
0xaaade03ad4b0<br>
0xaaac7f14d4b0<br>
0xaaabd7f0d4b0<br>
0xaaae553ed4b0<br>
0xaaac04d7d4b0<br>
0xaaad5b02d4b0<br>
0xaaaea137d4b0<br>
0xaaabdb2cd4b0<br>
0xaaabf431d4b0<br>
0xaaac933ad4b0<br>
0xaaab5564d4b0<br>
0xaaae84c5d4b0<br>
0xaaac2af5d4b0<br>
0xaaacf5ecd4b0<br>
0xaaad7d2bd4b0<br>
0xaaaba9e6d4b0<br>
0xaaae97cfd4b0<br>
0xaaab21d5d4b0<br>
0xaaad6c3bd4b0<br>
0xaaac01f9d4b0<br>
0xaaae7353d4b0<br>
0xaaabb5c7d4b0<br>
0xaaabd392d4b0<br>
0xaaab0787d4b0<br>
0xaaacdbd4d4b0<br>
0xaaabc8d2d4b0<br>
0xaaab6fafd4b0<br>
0xaaad8ef8d4b0<br>
0xaaab5bccd4b0<br>
0xaaae78f5d4b0<br>
0xaaada9b0d4b0<br>
0xaaacc4afd4b0<br>
0xaaab68dad4b0<br>
0xaaac9fd7d4b0<br>
0xaaab96f6d4b0<br>
0xaaac12a9d4b0<br>
0xaaac2c4bd4b0<br>
0xaaae8aa8d4b0<br>
0xaaac7d59d4b0<br>
0xaaab8f07d4b0<br>
0xaaad17dcd4b0<br>
0xaaabed8dd4b0<br>
0xaaae2a43d4b0<br>
0xaaac133dd4b0<br>
0xaaac5aa1d4b0<br>
0xaaae0e3fd4b0<br>
0xaaac04f5d4b0<br>
0xaaac2861d4b0<br>
0xaaae73ffd4b0<br>
0xaaab6d75d4b0<br>
0xaaae2e1ad4b0<br>
0xaaab7ccbd4b0<br>
0xaaad15a0d4b0<br>
0xaaacaba8d4b0<br>
0xaaab9004d4b0<br>
0xaaae57e6d4b0<br>
0xaaad7265d4b0<br>
0xaaabcc47d4b0<br>
0xaaac8b20d4b0<br>
0xaaadf688d4b0<br>
0xaaad361ed4b0<br>
0xaaabcb51d4b0<br>
0xaaab2894d4b0<br>
0xaaab4494d4b0<br>
0xaaae92e5d4b0<br>
0xaaab8093d4b0<br>
0xaaade01cd4b0<br>
0xaaac9051d4b0<br>
0xaaac3371d4b0<br>
0xaaab94fed4b0<br>
0xaaad70cbd4b0<br>
0xaaacdf29d4b0<br>
0xaaae5b0bd4b0<br>
0xaaac6e4fd4b0<br>
0xaaac9ec5d4b0<br>
0xaaad4e10d4b0<br>
0xaaac4a17d4b0<br>
0xaaae46b5d4b0<br>
0xaaac95acd4b0<br>
0xaaac86cbd4b0<br>
0xaaab57e2d4b0<br>
<br>
Evgenii Stepanov via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> writes:<br>
<br>
> Could you run the binary a few times and collect different code<br>
> addresses it complains about?<br>
> Could be a change in ASLR randomness.<br>
> It looks like the ranges in aarch64 shadow mapping are unnecessarily<br>
> restrictive.<br>
> I did not test this, but the following seems possible:<br>
> app-14 0x0AAA000000000 .. 0x0AAB000000000<br>
> shadow-14 0x0AAC000000000 .. 0x0AAD000000000<br>
> origin-14 0x0AAD000000000 .. 0x0AAE000000000<br>
><br>
> On Thu, Oct 25, 2018 at 6:42 AM David Greene via llvm-dev<br>
> <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
><br>
> Adhemerval Zanella via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> writes:<br>
> <br>
> > This seems to be printed by InitShadow and it is an<br>
> initialization routine<br>
> > which runs on all msan enabled binaries. The only issue I think<br>
> is runtime<br>
> > is set __msan_track_origins by -msan-track-origins=1 option and<br>
> unfortunately<br>
> > it does not seem to be stressed in any testcase. Is it the case<br>
> on this binary<br>
> > you are testing?<br>
> <br>
> These are existing tests in the repository. I don't see<br>
> -msan-track-origins set in the RUN lines so that can't be the only<br>
> thing<br>
> that enables this message.<br>
> <br>
> -David<br>
> _______________________________________________<br>
> LLVM Developers mailing list<br>
> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
><br>
> _______________________________________________<br>
> LLVM Developers mailing list<br>
> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div></div></div></div>