This is the mail archive of the
mailing list for the libstdc++ project.
Re: libstdc++/16612, empty basic_strings can't live in shared memory
Nathan Myers wrote:
On Thu, Aug 05, 2004 at 05:10:50PM -0700, Mark Mitchell wrote:I'm not enough of an expert to say for sure about these things. Do you
need the memory to be shared across cooperating processes, or just
allocated at the same address in all cooperating processes? If it's
read-only, I'm guessing the latter. In that case, you could probably
also use mmap, requesting a particular address. That will not work in
the fully general case, but it might well be possible to make it work
reliably on any given system by picking appropriate addresses. You
might also just be able to place an ELF section full of zeros in the
executable with a fixed load address.
Nathan Myers wrote:
I like the idea of using static space in libsupc++. It's simpler,It cannot be so arranged on some systems. For example, some systems
allocate memory to shared objects based on link order, so unless
libsupc++ is always the first library, one can't be sure it will end up
at the same place. Also, if multiple libraries want to be loaded at the
same address, the dynamic linker will have to pick one.
and should improve performance of the plain vanilla string, too, by
avoiding relocation indirections. Can anybody say whether it could
be arranged for static storage in libsupc++ to appear at the same
address in all programs compiled for a given ABI version?
Perhaps I shouldn't have been so specific. Might there already be
a block of 16 consecutive const (ideally, read-only) zero bytes in
crt1.o, or crti.o, or crtbegin.o at (a fixed offset from) an exported
symbol? Might such a block be added to (e.g.) crtbegin.o? There
might be plenty of other uses for such a thing besides std::string.
I don't think that the need for a fixed address in all programs is
in any way universal. I suspect that on most architectures, even
where it's not guaranteed, there would be a way to arrange to get a
common address, somehow, for (the few) programs that need it. Other
programs would benefit just from the faster access to a non-relocated