Re: objcopy --set-section-flags .data=alloc,load,data,share

[<peter dot kourzanov at xs4all dot nl>]

On Thu, Nov 11, 2004 at 11:21:56AM -0500, Ian Lance Taylor wrote:
> <peter.kourzanov@xs4all.nl> writes:
> 
> >   I was suspecting this. Can you briefly explain what the "share"
> > section flag does in formats that support it?
> 
> It is only supported by PE, where it corresponds to the
> IMAGE_SCN_MEM_SHARED flag.  Microsoft's documentation says it means
> "section can be shared in memory."  That is all I know about it.

  OK. Then my question would be - is it possible to somehow indicate
in the ELF header that the loader should take some special action when
setting up the mappings?

> 
> > What I am trying to
> > achieve is a shared copy-on-write section, which I know I pretty
> > much impossible on standard UNIX but nevertheless... The idea is to
> > have the .data of one process be accessible from another process,
> > with copied-on-write pages notwithstanding. To do that, the kernel's
> > loader needs to distinguish these "copy-on-write shared" sections 
> > from normal ones, hence my question.
> 
> It's presumably not what you are after, but you can construct
> something along these lines using mmap() with MAP_SHARED and
> MAP_PRIVATE.

  That's catch-22. Using MAP_SHARED on a .data segment in the first
process would mean all writes will hit the binary image. Using
MAP_PRIVATE, as of now, makes all writes local to the first process,
implying that the second process will only see initial values in
.data segment.  What I want is a dual of MAP_SHARED:MAP_PRIVATE,
in which local, rather than remote writes are shared.

  This can be done e.g., by actually copying the .data to a shared
memory segment and playing with MAP_SHARED from there.


> 
> Ian
> 

Pjotr.