From owner-freebsd-arch@FreeBSD.ORG  Thu May  1 09:02:03 2003
Return-Path: <owner-freebsd-arch@FreeBSD.ORG>
Delivered-To: freebsd-arch@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP
	id 62E6337B404; Thu,  1 May 2003 09:01:59 -0700 (PDT)
Received: from nagual.pp.ru (pobrecita.freebsd.ru [194.87.13.42])
	by mx1.FreeBSD.org (Postfix) with ESMTP
	id DAF4143F93; Thu,  1 May 2003 09:01:57 -0700 (PDT)
	(envelope-from ache@pobrecita.freebsd.ru)
Received: from pobrecita.freebsd.ru (ache@localhost [127.0.0.1])
	by nagual.pp.ru (8.12.9/8.12.9) with ESMTP id h41G1tnd055594;
	Thu, 1 May 2003 20:01:55 +0400 (MSD)
	(envelope-from ache@pobrecita.freebsd.ru)
Received: (from ache@localhost)
	by pobrecita.freebsd.ru (8.12.9/8.12.9/Submit) id h41G1tao055593;
	Thu, 1 May 2003 20:01:55 +0400 (MSD)
Date: Thu, 1 May 2003 20:01:55 +0400
From: "Andrey A. Chernov" <ache@nagual.pp.ru>
To: Daniel Eischen <eischen@pcnet1.pcnet.com>
Message-ID: <20030501160155.GB55078@nagual.pp.ru>
References: <20030501154139.GA54878@nagual.pp.ru>
	<Pine.GSO.4.10.10305011143400.11732-100000@pcnet1.pcnet.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.GSO.4.10.10305011143400.11732-100000@pcnet1.pcnet.com>
User-Agent: Mutt/1.5.4i
cc: freebsd-arch@freebsd.org
Subject: 
	Re: `Hiding' libc symbols (was Re: cvs commit: src/lib/libc/gen ...)
X-BeenThere: freebsd-arch@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Discussion related to FreeBSD architecture
	<freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
	<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
	<mailto:freebsd-arch-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 01 May 2003 16:02:03 -0000

On Thu, May 01, 2003 at 11:51:15 -0400, Daniel Eischen wrote:
> > Threads is completely another issue. We can do ANY tricks threads needs
> > when it is NOT affects normal linking (under "normal" I mean preventing
> > standard namespace replacement from outside of libc). If current
> > replacement way for threads not allows preventing, it should be changed
> > somehow to be truely libc internal, i.e. not explotable from outside of
> > libc/libc_r/other threads libs.
> 
> I'm not sure what you mean, but what we have works well.  There
> may be times that we want to call the internal _foo() and other
> times were we want to call foo().  How are you going to build
> a tool that can tell the difference if you reference foo() in both
> places?

Internal _names are the way threads tricks are implemented. I am looking
from outside of that scheme, so this details are not needed. From outside
of this scheme now I can replace, say, open() with anything I want
(because it is _ tricked in threads). It should not happens. I.e. open()  
replacement in threads should happens, but in linked application - not. It
means libc and libc_r must share some unusual replacement way which
application never can normally use.