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

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

[peter.kourzanov]

Hello,

  I've got a question about semantics of the "share" section flag
in objcopy. It seems not be documented anywhere and all links I
could google up refer to COFF binaries, with unexplained semantics
as well. Is there a possibility to mark a "shared" section in ELF,
so that OS's that need it can map the section as shared?

  I did try the invokation mentioned in the subject, it seems to
have no effect on the binary.

  TIA,

  Pjotr Kourzanov

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

[Ian Lance Taylor]

<peter.kourzanov@xs4all.nl> writes:

>   I've got a question about semantics of the "share" section flag
> in objcopy. It seems not be documented anywhere and all links I
> could google up refer to COFF binaries, with unexplained semantics
> as well. Is there a possibility to mark a "shared" section in ELF,
> so that OS's that need it can map the section as shared?

The "share" section flag can not be represented in ELF.

I'm not sure exactly what you mean by "map the section as shared," but
the answer is probably no: there is no way to do that in ELF.  Note
that typical ELF systems will automatically share read-only text
segments.

Ian

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

[peter.kourzanov]

  Ian,

  I was suspecting this. Can you briefly explain what the "share"
section flag does in formats that support it? 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.

  Pjotr.


On Thu, Nov 11, 2004 at 10:21:48AM -0500, Ian Lance Taylor wrote:
> <peter.kourzanov@xs4all.nl> writes:
> 
> >   I've got a question about semantics of the "share" section flag
> > in objcopy. It seems not be documented anywhere and all links I
> > could google up refer to COFF binaries, with unexplained semantics
> > as well. Is there a possibility to mark a "shared" section in ELF,
> > so that OS's that need it can map the section as shared?
> 
> The "share" section flag can not be represented in ELF.
> 
> I'm not sure exactly what you mean by "map the section as shared," but
> the answer is probably no: there is no way to do that in ELF.  Note
> that typical ELF systems will automatically share read-only text
> segments.
> 
> Ian
> 

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

[Ian Lance Taylor]

<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.

> 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.

Ian

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

[peter.kourzanov]

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.

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

[Ian Lance Taylor]

<peter.kourzanov@xs4all.nl> writes:

>   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?

No.  At least, I don't know of any such thing.

Ian