Looking how a running program is laid out in memory we can see how
things changed and moved around.
Old kernel:
10000000-10010000 r-xp 00000000 fd:02 3192069 pgm
10010000-10020000 rw-p 00000000 fd:02 3192069 pgm
80c52e0000-80c5310000 r-xp 00000000 fd:00 2228231
/lib64/ld-2.12.so
80c5310000-80c5320000 r--p 00020000 fd:00 2228231
/lib64/ld-2.12.so
80c5320000-80c5330000 rw-p 00030000 fd:00 2228231
/lib64/ld-2.12.so
80c5330000-80c54f0000 r-xp 00000000 fd:00 2228242
/lib64/libc-2.12.so
80c54f0000-80c5500000 r--p 001b0000 fd:00 2228242
/lib64/libc-2.12.so
80c5500000-80c5520000 rw-p 001c0000 fd:00 2228242
/lib64/libc-2.12.so
fff842e0000-fff84300000 r-xp 00000000 00:00 0
[vdso]
fffc2ac0000-fffc2c10000 rw-p 00000000 00:00 0
[stack]
New kernel:
10000000-10010000 r-xp 00000000 fc:00 32966843 pgm
10010000-10020000 r--p 00000000 fc:00 32966843 pgm
10020000-10030000 rw-p 00010000 fc:00 32966843 pgm
3fff97730000-3fff978e0000 r-xp 00000000 08:02 12452256
/lib/powerpc64le-linux-gnu/libc-2.23.so
3fff978e0000-3fff978f0000 r--p 001a0000 08:02 12452256
/lib/powerpc64le-linux-gnu/libc-2.23.so
3fff978f0000-3fff97900000 rw-p 001b0000 08:02 12452256
/lib/powerpc64le-linux-gnu/libc-2.23.so
3fff97930000-3fff97950000 r-xp 00000000 00:00 0
[vdso]
3fff97950000-3fff97990000 r-xp 00000000 08:02 12452170
/lib/powerpc64le-linux-gnu/ld-2.23.so
3fff97990000-3fff979a0000 r--p 00030000 08:02 12452170
/lib/powerpc64le-linux-gnu/ld-2.23.so
3fff979a0000-3fff979b0000 rw-p 00040000 08:02 12452170
/lib/powerpc64le-linux-gnu/ld-2.23.so
3ffffda10000-3ffffda40000 rw-p 00000000 00:00 0
[stack]
Note that this changes again with the even newer powerpc64 kernel that
uses a 47 bit VMA (previously 44/46).
On 10/04/2017 03:03 PM, Evgenii Stepanov via llvm-dev
wrote:> Hi,
>
> this is easier to understand by reading msan source in compiler-rt.
> See MappingDesc, CheckMemoryLayoutSanity(), InitShadow().
> Specifically, these constants must match the definitions of
> MEM_TO_SHADOW and SHADOW_TO_ORIGIN.
>
> Basically, you need to identify all possible memory addresses that may
> be occupied by the time MSan is initialized. These are usually binary
> and library mappings, main thread stack, etc. Think about different
> modes like ASLR on/off, pie/no-pie, etc. All of these addresses, plus
> the heap (see kAllocatorSpace, you control that) must belong to
> MappingDesc::APP regions. See CheckMemoryLayoutSanity for other
> constraints.
>
> On Wed, Oct 4, 2017 at 8:34 AM, Nemanja Ivanovic
> <nemanja.i.ibm at gmail.com> wrote:
>> It would appear that the fix for
https://bugs.llvm.org/show_bug.cgi?id=24155
>> really only applies to X86. Which I suppose is fine since that's
where the
>> bug was reported.
>>
>> However, we've recently upgraded the OS's on some of our PPC64
systems and
>> are hitting the same problems. I certainly wouldn't mind providing
a similar
>> fix for PPC, but I don't know what the values in MemoryMapParams
mean nor
>> what they should be set to.
>>
>> I am hoping that someone can explain to me what those mean and what
they
>> should be set to as well as how this relates to the kernel we're
on.
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
--
-Bill Seurer