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
On Thu, Aug 05, 2004 at 05:10:50PM -0700, Mark Mitchell wrote:
> Nathan Myers wrote:
> >I like the idea of using static space in libsupc++. It's simpler,
> >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?
> 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.
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