Document another limitation of the Solaris port

regarding to AT_SUN_SYSSTAT_ADDR and AT_SUN_SYSSTAT_ZONE_ADDR.
n-i-bz

git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15506

diff --git a/README.solaris b/README.solaris
index 924eb2fcaded26ad1f483583089a7d8b6b342f09..6bc8eec4a578409cf1a451eb0bfea990d1d03b4d 100644 (file)
--- a/README.solaris
+++ b/README.solaris
@@ -79,6 +79,15 @@ Limitations
   possible for Valgrind to arrange mapping of a kernel shared page at the
   address specified in the mapfile for the guest application. There is currently
   no such mechanism in Solaris. Hacky workarounds are possible, though.
+- Guest programs do not contain entries for AT_SUN_SYSSTAT_ADDR and
+  AT_SUN_SYSSTAT_ZONE_ADDR in their auxilliary vectors. There is no direct way
+  how to obtain addresses of these pages shared with the kernel as they are
+  passed in auxv and kernel does not create auxv for statically linked binaries
+  (such as Valgrind analysis tools).
+  Indirect methods, such as scanning 1-page mappings found at Valgrind
+  startup surrounded by reservations, could be possible. But it is hard to tell
+  which page is which because their contents are filled only when a system
+  cyclic is started. See get_hrusec() for reference.
 - When a thread has no stack then all system calls will result in Valgrind
   crash, even though such system calls use just parameters passed in registers.
   This should happen only in pathological situations when a thread is created