Re: gABI extension proposal: PT_SHMMAP

["H. Peter Anvin" <hpa@zytor.com>]

On 06/08/17 09:19, Suprateeka R Hegde wrote:
> On 07-Jun-2017 10:40 PM, H. Peter Anvin wrote:
>> Any particular reason that you feel this is not generally useful?
> 
> 1. The use case provided looks extremely specific to Linux. AFAIK, none
> of the unix like HP-UX, Solaris or AIX need this requirement.
> 
> 2. This looks so specific to a runtime loader that it can be as well
> handled as a special case in GNU mmap system (may be in ld.so).
> 
> 3. Assuming Cary is right in understanding that you want a writable but
> still sharable page, such features are not even provided by some of the
> legacy unix kernels.
> 
> 4. Eventually there can be many such flags if we start going with
> specific claims. For instance there was a request for
> PF_NOREAD/SHF_NOREAD that would help some archs (STM?) to protect code
> from being read.
> 

SHF_NOREAD makes total sense - there is no real reason for the current
asymmetry
between the SHF and the PF flags -- you don't need PF_NOREAD because you
already
have PF_R, but there is no SHF_ flag to indicate that a the resulting
segment
should be linked to be !PF_R.

My proposal is also missing that aspect (see below.)


> 5. Why dont we try to fit this proposal under the bigger one - program
> properties - proposed by H.J. ? The theme there is to pass such
> information to runtime.

I think this is completely orthogonal - that would be a program property
rather than a per-segment property?

> 6. Lastly, the proposal looks incomplete:
> 5-a. The hex value for the proposed flag is missing
> 5-b. The proposal should be sent to Generic SYS-V ABI group and not
> GNU-GABI alone.

That is certainly true, but H.J. suggested vetting it here first,
exactly to get the t's crossed and the i's dotted first.  The PT_ vs PF_
question was one.

> 5-c. The complete semantics of this flag in a standard form. The
> semantics should talk about what is mandatory, what is optional. Is the
> current/existing UNIX should be changed to honor this flag or is this
> optional?

So, a slightly refined proposal (if these numbers conflict with newer
allocations/proposals please let me know):


0x00000008 (2^3) - PF_SHARED

	This segment MUST be memory-mapped using MAP_SHARED.  Not
	all operating systems need to support this capability.  If this
	is not possible due to lack of operating system support or
 	because the underlying image is not possible to memory-map,
	the loading of the image should be aborted with an error.

0x00001000 (2^12) - SHF_SHARED

	This section MUST be made part of a PF_SHARED segment when
	linked.

OPTIONALLY, new reserved section names:

	.shrodata	- readonly data section to be mapped shared
	.shdata		- writable data section to be mapped shared
	.shbss		- zerofill section to be mapped shared