Re: obsoleting shlibs - what's the plan

[David Holland <dholland-tech%netbsd.org@localhost>]

On Mon, Apr 14, 2008 at 08:48:19AM +0200, Joerg Sonnenberger wrote:
 > On Mon, Apr 14, 2008 at 03:52:02AM +0000, David Holland wrote:
 > > On Sat, Mar 29, 2008 at 12:36:14PM +0900, Joerg Sonnenberger wrote:
 > > > > It's also not clear that loading two instances of the "same" library
 > > > > is necessary wrong in all cases. For example, a library that provided
 > > > > the functions in <string.h> could be cloned fairly safely, whereas two
 > > > > different mallocs is clearly a losing proposition no matter what you
 > > > > do.
 > > > 
 > > > A different malloc is actually safe as well as long as you implement the
 > > > whole family.
 > > 
 > > Not really. If a pointer returned by one malloc's malloc makes its way
 > > to the other malloc's free, nothing good can possibly happen.
 > 
 > I am not talking about mixing mallocs. I am talking about *replacing*
 > one completely. 

I was talking about mixing mallocs, that is, having two different
instances appearing in the same process.

Replacing malloc is supposed to work, yes.

 > Given that it is not supposed to have a hidden
 > interface, it has to work. The list of symbols to override has recently
 > changed though as some people assumed posix_memalign is a bright idea.

One of the other less urgent things I don't like about ELF is that
when you go to replace something like malloc, there's no way to set
things up so you can find out that you've forgotten one at link time;
you have to wait for the nasal demons to show up.

 > > Also, with many malloc implementations they'll fight over the process
 > > break and get seriously confused.
 > 
 > I would expect a modern malloc implement to not use anachronistic
 > interfaces. mmap is almost always superior to break.

My vague impression is that many mallocs use both; anyway, some do.

 > >  > At least libpthread and libc should check explicitly that
 > >  > they are loaded only once. In the caes of libpthread, it should also
 > >  > check and fail miserable when it is loaded via dlopen.
 > > 
 > > It's not clear that this can be done without help from the dynamic
 > > linker.
 > 
 > Constructor is enough for libc 

Hrm... yes, I think that'll work, because (I think) all copies will be
constructed. Or at least, they should be.

 > and libpthread has an explicit init call already.

That won't, because it's a symbol and will resolve to only one of the
loaded instances.

-- 
David A. Holland
dholland%netbsd.org@localhost