When using shared libraries, is there a ".section" into which
I can put a variable that's writable? I note that when programs
that use shared libraries start, the pages are mprotect(ed)
PROT_READ|PROT_EXEC, but sometimes I see PROT_WRITE on some
pages.
I'd like to rip out a memory-mapped semiphore and put it directly
in a shared library if possible.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
The US military has given us many words, FUBAR, SNAFU, now ENRON.
Yes, top management were graduates of West Point and Annapolis.
On 2002.10.09 Richard B. Johnson wrote:
>
>
> When using shared libraries, is there a ".section" into which
> I can put a variable that's writable? I note that when programs
> that use shared libraries start, the pages are mprotect(ed)
> PROT_READ|PROT_EXEC, but sometimes I see PROT_WRITE on some
> pages.
>
> I'd like to rip out a memory-mapped semiphore and put it directly
> in a shared library if possible.
>
A library can define global variables visible to others, has its own BSS:
int x;
void f()
{
}
built with gcc -shared, and nm'ed gives:
00000694 T f
000017f8 B x
000016f8 D y
from man nm:
"B" The symbol is in the uninitialized data section (known as BSS).
"D" The symbol is in the initialized data section.
"T" The symbol is in the text (code) section.
Was about this or I misunderstood you ?
--
J.A. Magallon <[email protected]> \ Software is like sex:
werewolf.able.es \ It's better when it's free
Mandrake Linux release 9.1 (Cooker) for i586
Linux 2.4.20-pre10-jam1 (gcc 3.2 (Mandrake Linux 9.0 3.2-2mdk))
On Wed, 9 Oct 2002, J.A. Magallon wrote:
>
> On 2002.10.09 Richard B. Johnson wrote:
> >
> >
> > When using shared libraries, is there a ".section" into which
> > I can put a variable that's writable? I note that when programs
> > that use shared libraries start, the pages are mprotect(ed)
> > PROT_READ|PROT_EXEC, but sometimes I see PROT_WRITE on some
> > pages.
> >
> > I'd like to rip out a memory-mapped semiphore and put it directly
> > in a shared library if possible.
> >
>
> A library can define global variables visible to others, has its own BSS:
>
> int x;
>
> void f()
> {
> }
>
> built with gcc -shared, and nm'ed gives:
>
> 00000694 T f
> 000017f8 B x
> 000016f8 D y
>
> from man nm:
> "B" The symbol is in the uninitialized data section (known as BSS).
> "D" The symbol is in the initialized data section.
> "T" The symbol is in the text (code) section.
>
> Was about this or I misunderstood you ?
No. You did not misunderstand. If I declare a variable and put it
into a shared library, I seem to get one of two different behaviors.
If the variable is initialized, it goes into the ".data" section.
If the variable is not initialized, it goes into the ".bss" section.
Non-writable strings go into ".rodata"
In the case of data in the .bss section, if one procedure writes to
this variable, it is not seen by other procedures that are linked
to the shared library. However it can write with no problem and it
can read what it wrote. Apparently ".bss" data are not really allocations
in shared memory, only a promise to allocate some data when the program
is loaded and this data is not shared, it's private to the process.
If a variable is in the ".data" section, it is "seen" by all procedures
that are linked to the shared library, but any attempt to write to this
variable will seg-fault the task that attempts to modify it.
I would like to be able to write to that variable and have it seen
by other tasks, since shared memory is shared memory. It's a shame
to mmap a shared library upon startup and then have to mmap some
additional shared memory for some inter-process communication.
So, is there a "section" that, when mmapped by the loader will
not protect it from writes?
Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
The US military has given us many words, FUBAR, SNAFU, now ENRON.
Yes, top management were graduates of West Point and Annapolis.
"Richard B. Johnson" <[email protected]> writes:
|> If a variable is in the ".data" section, it is "seen" by all procedures
|> that are linked to the shared library, but any attempt to write to this
|> variable will seg-fault the task that attempts to modify it.
Your tests must be flawed, because a .data section *is* writable. The
only difference between .data and .bss is that the latter has no
allocation in the image file, but they are mapped to the same, writable
segment.
Andreas.
--
Andreas Schwab, SuSE Labs, [email protected]
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 N?rnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
On Wed, 9 Oct 2002, Andreas Schwab wrote:
> "Richard B. Johnson" <[email protected]> writes:
>
> |> If a variable is in the ".data" section, it is "seen" by all procedures
> |> that are linked to the shared library, but any attempt to write to this
> |> variable will seg-fault the task that attempts to modify it.
>
> Your tests must be flawed, because a .data section *is* writable. The
> only difference between .data and .bss is that the latter has no
> allocation in the image file, but they are mapped to the same, writable
> segment.
>
> Andreas.
Well, yes I found out.. This anomaly with the assembler.....
.section .data
.global pars
.type pars,@object
.size pars,4
.align 4
pars: .long 0
.end
I accidentally left out .size, guess what? Even though I had an
offset recognized and a ".long", initialized to 0, there was no
space allocated and therefore the seg-fault. I would have seen
this, but the problem doesn't exist if the ".section" is ".bss",
the first section I was messing with. Go figure?
And the writable, is a COW. It isn't seen by others. It's a shame.
It would be very useful to have a writable global section available
like VAXen did.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
The US military has given us many words, FUBAR, SNAFU, now ENRON.
Yes, top management were graduates of West Point and Annapolis.
"Richard B. Johnson" <[email protected]> writes:
|> Well, yes I found out.. This anomaly with the assembler.....
|>
|> .section .data
|> .global pars
|> .type pars,@object
|> .size pars,4
|> .align 4
|> pars: .long 0
|> .end
|>
|>
|> I accidentally left out .size, guess what? Even though I had an
|> offset recognized and a ".long", initialized to 0, there was no
|> space allocated and therefore the seg-fault. I would have seen
|> this, but the problem doesn't exist if the ".section" is ".bss",
|> the first section I was messing with. Go figure?
I think this problem only exists on platforms with COPY relocations.
Andreas.
--
Andreas Schwab, SuSE Labs, [email protected]
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 N?rnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Richard B. Johnson wrote:
> In the case of data in the .bss section, if one procedure writes to
> this variable, it is not seen by other procedures that are linked
> to the shared library. However it can write with no problem and it
> can read what it wrote. Apparently ".bss" data are not really allocations
> in shared memory, only a promise to allocate some data when the program
> is loaded and this data is not shared, it's private to the process.
You are mixing up two very different concepts.
Writes to both .bss and .data allocations are seen by _all_ procedures
that are linked together. Run-time linking is within a single
processes only. So writes to any section are private to the process
which does the writes.
.bss and .data are nearly the same thing: writable, process-private
areas. The only difference is that .data is initialised from the
shared library file, while .bss is initialised with zeros.
Don't think about "mapping" a shared library, because the mappings
aren't like shared memory between processes. That's misleading if you
come from a VAX or Windows background, where they are.
Think about "loading" a shared library instead: as if you'd allocated
private memory in a process and then copied the library file into that
memory. You could rewrite the ELF loader to use malloc+read+mprotect,
and every program should continue to work.
(Ignore the fact that mmap() is used: it's an optimisation which
doesn't change the behaviour of the program).
> If a variable is in the ".data" section, it is "seen" by all procedures
> that are linked to the shared library, but any attempt to write to this
> variable will seg-fault the task that attempts to modify it.
No it won't. (Unless you managed to declare the ".data" section read
only, which is not possible normally, but may be possible with certain
tiny assembly language test programs).
> I would like to be able to write to that variable and have it seen
> by other tasks, since shared memory is shared memory.
Note that, in unix terminology, the phrase "linked to a shared
library" means linkage within a single private process only, and
the term "shared library" has very little to do with "shared memory".
This is not like Windows, where there is effectively one instance of
the shared library mapped and shared between processes, and the
library knows about the multiple processes that are using it.
In Linux each process creates its _own_ instance of the library at
load time, and each of those instances is private to the process that
created it.
> It's a shame to mmap a shared library upon startup and then have to
> mmap some additional shared memory for some inter-process
> communication.
Perhaps but it does force you to think about what extent of sharing
you really want, instead of giving you the one option which is often
wrong.
There are occasions when you'd want multiple processes per user to
share some data, but different users to _not_ share anything. There
are other occasions when you want different users to share data.
Sometimes you'd really like the data shared within a cluster instead
of on a single machine. Sometimes you'd like the data shared per X
server, for example a web browser using a process per browser window
might need this.
You said you wanted the shared area for a semaphore. Ok, but what is
the semaphore protecting? If it's access to a file such as a
database, the semaphore should be _network_ wide because files are not
always local.
If it's protecting access to a set of per-user files, map a lock file
in each user's home directoy. If it's a scoreboard for a host-wide
service such as a web server, it wants to use a host-wide file such as
in /var/run for example.
In general, a semaphore should have similar scope to the thing it's
protecting. So, a file lock for a file or set of related files; a
thread semaphore to protect data in a thread from other threads; an
inter-process semaphore using explicit IPC if you have an explicitly
shared segment; a network daemon to synchronise access to a network
wide resource, etc.
Btw, take a look at pthreads especially the latest Glibc pthreads
thing Ulrich & Ingo have worked on. It offers fast & precise
inter-thread (process scope) and inter-process semaphores, based on
futexes, I believe.
-- Jamie