From owner-freebsd-arch@FreeBSD.ORG Thu May 1 09:13:34 2003 Return-Path: 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 CCF3737B404; Thu, 1 May 2003 09:13:34 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 18C4443F3F; Thu, 1 May 2003 09:13:34 -0700 (PDT) (envelope-from eischen@pcnet1.pcnet.com) Received: from pcnet1.pcnet.com (localhost [127.0.0.1]) by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h41GDWBg018359; Thu, 1 May 2003 12:13:32 -0400 (EDT) Received: from localhost (eischen@localhost)h41GDV28018352; Thu, 1 May 2003 12:13:31 -0400 (EDT) Date: Thu, 1 May 2003 12:13:31 -0400 (EDT) From: Daniel Eischen To: "Andrey A. Chernov" In-Reply-To: <20030501160155.GB55078@nagual.pp.ru> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2003 16:13:35 -0000 On Thu, 1 May 2003, Andrey A. Chernov wrote: > 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. libc foo() wants to call _open(). libc bar() wants to call open(). If both foo() and bar() now reference open() and the ache tool converts all references to open to _open, now both foo() and bar() call _open(). namespace.h also gets rid of compiler errors when you reference _open instead of open. -- Dan Eischen