uweigand added inline comments.

================
Comment at: compiler-rt/lib/tsan/rtl/tsan_platform_posix.cpp:123
+#if defined(__s390x__)
+  ProtectRange(HiAppMemEnd(), 0xfffffffffffff000ull);
+#endif
----------------
iii wrote:
> uweigand wrote:
> > Did you test this on older kernels without 5-level page table support?   I 
> > believe the allocation / mprotect may fail on those ...
> No, not really. Would it make sense to probe here? E.g. first try 
> 0xfffffffffffff000, then 0x20000000000000. Or is there a way to query 
> user_addr_max() / TASK_SIZE_MAX / TASK_SIZE?
I don't know of any way to query this.  You can simply do the allocation in 
stages (first to the top of the three-pagetable range, then four, then five), 
and ignore failures.   As an unfortunate side effect this will force the kernel 
to allocate five levels of page tables even when unnecessary, but I don't think 
there's anything we can do about that.


================
Comment at: compiler-rt/lib/tsan/rtl/tsan_rtl_s390x.S:22
+  CFI_REL_OFFSET(%r2, R2_REL_OFFSET)
+  CFI_REL_OFFSET(%r3, R3_REL_OFFSET)
+  stmg %r14, %r15, R14_REL_OFFSET(%r15)
----------------
iii wrote:
> uweigand wrote:
> > Do we need CFI for r2/r3 ?  Those are call-clobbered any cannot be unwound 
> > normally anyway ...
> I'm not quite sure, but glibc does this (e.g. in 
> sysdeps/s390/s390-64/dl-trampoline.h), so I figured I'll do this here as well 
> just in case.
Huh.   Well I guess it doesn't hurt either way.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D105629/new/

https://reviews.llvm.org/D105629

_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to