Fixing dlopen("libpthread.so")

[Konstantin Belousov]

On Tue, Jan 06, 2015 at 11:01:30PM -0500, Daniel Eischen wrote:
> On Wed, 7 Jan 2015, Konstantin Belousov wrote:
> 
> > On Tue, Jan 06, 2015 at 09:50:46PM +0100, Jilles Tjoelker wrote:
> >> On Mon, Jan 05, 2015 at 04:37:08AM +0200, Konstantin Belousov wrote:
> >>> Next natural question is about the __error calls through PLT in the
> >>> .cerror asm. Before the work was committed, libthr interposed __error,
> >>> which was required for correct operation. Now, we need __error exported,
> >>> but do we need support its interposing ? This is an implementation
> >>> detail for errno, I do not see any loss from not allowing to override
> >>> errno location.
> >>
> >> Indeed, there is no need to allow interposing __error (as with many
> >> libc-internal calls to its exported symbols). Additionally, the current
> >> namespace.h mechanism could be used to redirect __error calls from C
> >> code.
> >>
> >> Glibc uses macro trickery with the asm labels compiler feature, making
> >> libc code see things like
> >>   int *__error(void) asm("__hidden__error");
> >> and defining the hidden alias somewhere. This also works for
> >> compiler-generated calls like to memcpy(). I'm not sure whether it is a
> >> good idea to add this extra trickery and depend on the compiler feature.
> > I might look at this after the current change is committed.
> 
> I don't quite follow all the above about __error(), but non-C
> programs need to interface to an __error() that works regardless
> of threading or not.

C programs also need to be able to call __error(), to have working
errno. Discussion above talks about the need for the programs to be
able to interpose __error(), which I and Jilles agree is excessive. My
proposal is to remove PLT indirection in the calls to __error() from
_inside_ libc, which makes errno functioning in libc both more reliable
and slightly faster.