https://bugs.kde.org/show_bug.cgi?id=468575
--- Comment #78 from Mark Wielaard <m...@klomp.org> ---
(In reply to JojoR from comment #10)
> (In reply to Petr Pavlu from comment #9)
> > (In reply to Paul Floyd from comment #8)
> > > Are the other failures "reaonable"?
> >
> > > memcheck/tests/sh-mem-random (stdout)
> > > memcheck/tests/sh-mem-random (stderr)
> >
> > Another unexpected mmap() failure.
>
> From our investigation, high address mmap is not supported by some riscv
> board/os if it support feature "Sv39" only,
> so it is reasonable also :)
Found that there are there are other arches that restrict highest user space
address, so I propose the following patch which makes sh-mem-random pass on the
risc-v systems I have access to and still seems a reasonable value for other
arches:
diff --git a/memcheck/tests/sh-mem-random.c b/memcheck/tests/sh-mem-random.c
index ae82248ae690..0e01684acb61 100644
--- a/memcheck/tests/sh-mem-random.c
+++ b/memcheck/tests/sh-mem-random.c
@@ -247,7 +247,10 @@ int main(void)
int nbytes_p;
// (U1*)(UWord)constULL funny casting to keep gcc quiet on
// 32-bit platforms
- U1* huge_addr = (U1*)(UWord)0x6600000000ULL; // 408GB
+ // https://www.kernel.org/doc/html/next/riscv/vm-layout.html
+ // Says RISC-V Linux Kernel SV39 user-space virtual memory
+ // ends at 256GB. So try at 240GB.
+ U1* huge_addr = (U1*)(UWord)0x3c00000000ULL; // 240GB
// Note, kernel 2.6.? on Athlon64 refuses fixed mmap requests
// at above 512GB.
--
You are receiving this mail because:
You are watching all bug changes.
