RE: Notes from the Sep 27 teleconference

>PR 99/100 we recommend rejection. A 32-bit process should
>behave as if it has 32-bit memory addresses even though it
>is running on 64-bit hardware.

I'm going back and thinking about this kind of problem when
it's come up before.  At least when we were running into this
in an emulation environment, the layout of memory could be
different in an emulated process than it was for a native one.
In particular, instead of being allocated in separate segments,
the process had to be presented in a single native segment.
It is my understanding that the layout is not specified in
the LSB or the other referenced documents.

The problem I recall us running into, and seems to be reflected
in the analysis of both bugs 1068 and 684 (which are both
about this issue, we should really combine them but there's
so much material in both I'm reluctant to do so), is that
the test strategy of using some experimentally determined
VSX_ADDR_SPACE_PAGES to "fall off the end" of a segment and
thus be able to test off-the-edge error conditions gets us
into trouble.  Just historically, there are exactly four
testcases that use this parameter, LSB.os {mmap 29, mmap 34,
munmap 4, mprotect 8}. Each one of these has been the source
of trouble - just check the email logs, the wiki page on
test results, etc.  On 64-bit architectures we've sort of informally
given up and decided there isn't really a value that makes
these tests work out reliably, although we do have values 
in place. The issue is these are determined almost by trial
and error in one particular circumstance, not derived from
something written in the specification, and just because it
worked one way doesn't mean it's right for some other circumstance.

In fact, old TSD.0022 (PR0034) is directly in this same space,
where the large value of the constant ended up unmapping
the system libraries.  In PR098/PR099 is it believed that a 
large value is causing the protections to be set inappropriately
on system libraries.

Remember the claim in the PR is that the specific mprotect
call being tested for in fact gives the result the specification
requires it to (ENOMEM), but subsequently since the process 
image is no longer set up correctly, the test ends up hanging,
is eventually killed by the testcase controller, and we get
an UNREPORTED result.  The specification is even explicit that
something like this may happen ("when mprotect() fails for a reason
other than [EINVAL], the protections on some of the pages in
the range [addr,addr+len] may have been changed") and it seems
to be particularly this side effect that is hanging the test.