Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 06 May 2003 21:49:10 -0700
From:      Terry Lambert <tlambert2@mindspring.com>
To:        "Jacques A. Vidrine" <nectar@FreeBSD.org>
Cc:        freebsd-arch@freebsd.org
Subject:   Re: `Hiding' libc symbols
Message-ID:  <3EB89046.F7128C8A@mindspring.com>
References:  <20030501182820.GA53641@madman.celabo.org> <XFMail.20030501144502.jhb@FreeBSD.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>

next in thread | previous in thread | raw e-mail | index | archive | help
"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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3EB89046.F7128C8A>