From owner-freebsd-arch@FreeBSD.ORG Tue May 6 21:50:37 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 3A23437B401; Tue, 6 May 2003 21:50:37 -0700 (PDT) Received: from heron.mail.pas.earthlink.net (heron.mail.pas.earthlink.net [207.217.120.189]) by mx1.FreeBSD.org (Postfix) with ESMTP id 67EB843FA3; Tue, 6 May 2003 21:50:36 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0555.cvx40-bradley.dialup.earthlink.net ([216.244.44.45] helo=mindspring.com) by heron.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 19DGt0-0007k6-00; Tue, 06 May 2003 21:50:35 -0700 Message-ID: <3EB89046.F7128C8A@mindspring.com> Date: Tue, 06 May 2003 21:49:10 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Jacques A. Vidrine" References: <20030501182820.GA53641@madman.celabo.org> <20030505110601.H53365@beagle.fokus.fraunhofer.de> <20030505175426.GA19352@madman.celabo.org> <20030506092519.GA3158@cirb503493.alcatel.com.au> <3EB7CC73.9C61C27E@mindspring.com> <20030506152557.GD77708@madman.celabo.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a42b992a946c257371dd0c2e29e38ec613a7ce0e8f8d31aa3f350badd9bab72f9c350badd9bab72f9c cc: freebsd-arch@freebsd.org Subject: Re: `Hiding' libc symbols 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: Wed, 07 May 2003 04:50:37 -0000 "Jacques A. Vidrine" wrote: > On Tue, May 06, 2003 at 07:53:39AM -0700, Terry Lambert wrote: > > Perhaps instead of asking how to prevent symbol replacement, one > > should be asking how to get rid of incestuous functions in the > > library implementation for standard library functions. > > > > No, I do not expect "_fmt" (or whatever) to go away from common > > code in printf/sprintf/whatever. But I do expect it to be "_fmt" > > instead of "fmt", i.e. in implementation space, rather than in > > the symbol space legal for users to use. > > This is exactly what I wish to achieve. This is exactly the approach > that I took with strlcpy [1]: the internal implementation is called > `_strlcpy', while the exported symbol remains `strlcpy'. I have no problem at all, so long as _strlcpy() isn't an exposed function, i.e., there is no strlcpy() that calls _strlcpy(), doing nothing else. I.e.: if there are internal functions in the library, they should not have external implementation. For A(), B(), and C(), all of which use the functionality of C(), I think the correct thing to do is to either repeat the code in each function, or make the code depend on some inline function, i.e. __A() and __B() call _libc_C(), and __C() has a seperate implementation; then A() is weakly bound to __A(), B() to __B(), and C() to __C(). Then you *remove* _libc_C() from the symbol table (it's either an inline, or you have to use explicit symbol sets and the linker). Then you can override the function, no problem. Otherwise you are screwed when it comes to profiling. -- Terry