* objcopy --set-section-flags .data=alloc,load,data,share [not found] <1100168375.22757.ezmlm@sources.redhat.com> @ 2004-11-11 10:26 ` peter.kourzanov 2004-11-11 15:22 ` Ian Lance Taylor 0 siblings, 1 reply; 6+ messages in thread From: peter.kourzanov @ 2004-11-11 10:26 UTC (permalink / raw) To: binutils 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: objcopy --set-section-flags .data=alloc,load,data,share 2004-11-11 10:26 ` objcopy --set-section-flags .data=alloc,load,data,share peter.kourzanov @ 2004-11-11 15:22 ` Ian Lance Taylor 2004-11-11 16:00 ` peter.kourzanov 0 siblings, 1 reply; 6+ messages in thread From: Ian Lance Taylor @ 2004-11-11 15:22 UTC (permalink / raw) To: peter.kourzanov; +Cc: binutils <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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: objcopy --set-section-flags .data=alloc,load,data,share 2004-11-11 15:22 ` Ian Lance Taylor @ 2004-11-11 16:00 ` peter.kourzanov 2004-11-11 16:22 ` Ian Lance Taylor 0 siblings, 1 reply; 6+ messages in thread From: peter.kourzanov @ 2004-11-11 16:00 UTC (permalink / raw) To: binutils 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 > ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: objcopy --set-section-flags .data=alloc,load,data,share 2004-11-11 16:00 ` peter.kourzanov @ 2004-11-11 16:22 ` Ian Lance Taylor 2004-11-11 16:40 ` peter.kourzanov 0 siblings, 1 reply; 6+ messages in thread From: Ian Lance Taylor @ 2004-11-11 16:22 UTC (permalink / raw) To: peter.kourzanov; +Cc: binutils <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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: objcopy --set-section-flags .data=alloc,load,data,share 2004-11-11 16:22 ` Ian Lance Taylor @ 2004-11-11 16:40 ` peter.kourzanov 2004-11-11 19:38 ` Ian Lance Taylor 0 siblings, 1 reply; 6+ messages in thread From: peter.kourzanov @ 2004-11-11 16:40 UTC (permalink / raw) To: binutils 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. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: objcopy --set-section-flags .data=alloc,load,data,share 2004-11-11 16:40 ` peter.kourzanov @ 2004-11-11 19:38 ` Ian Lance Taylor 0 siblings, 0 replies; 6+ messages in thread From: Ian Lance Taylor @ 2004-11-11 19:38 UTC (permalink / raw) To: peter.kourzanov; +Cc: binutils <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 ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2004-11-11 19:38 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <1100168375.22757.ezmlm@sources.redhat.com> 2004-11-11 10:26 ` objcopy --set-section-flags .data=alloc,load,data,share peter.kourzanov 2004-11-11 15:22 ` Ian Lance Taylor 2004-11-11 16:00 ` peter.kourzanov 2004-11-11 16:22 ` Ian Lance Taylor 2004-11-11 16:40 ` peter.kourzanov 2004-11-11 19:38 ` Ian Lance Taylor
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).