Re: fixing libpthread noload, another approach

[Emmanuel Dreyfus <manu%netbsd.org@localhost>]

On Mon, Feb 04, 2013 at 03:46:35PM +0200, Alan Barrett wrote:
> Instread of the previous "allow dlopen of libpthread, but fail or
> give undefined behaviour when thread-related functions are actually
> used", we now have "prohibit dlopen of libpthread".
> 
> You say that this is a regression, but other people think it's an
> improvement.

There are two cases.

case 1: dlopen of DSO that is linked with -lpthread through third pary 
libraries, but never use threads. That worked reliabily before NetBSD 6.0 
and now this is borken. This is a regression.

case 2: dlopen of DSO that do use threads in a programs that is not linked 
with -lpthread. That failed or gave an inconsitent behavior, now it 
reliabily fail. This is an improvement.

My proposed change would move to the situation where case 2 would see
an improvemnt while case 1 would not see a regression. This means:

case 1: dlopen succeed but do not load libpthread, and the case works 
reliabily as it did before 6.0

case 2: dlopen succeed, does not load libpthread but resolves its symbols
to an error stub that aborts the program. The program reliabily fails as 
soon as it actually use pthread stuff like pthread_create.

-- 
Emmanuel Dreyfus
manu%netbsd.org@localhost