This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

Nathan Myers
ncm-nospam@cantrip.org


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]