Date: Thu, 1 May 2003 20:01:55 +0400 From: "Andrey A. Chernov" <ache@nagual.pp.ru> To: Daniel Eischen <eischen@pcnet1.pcnet.com> Cc: freebsd-arch@freebsd.org Subject: Re: `Hiding' libc symbols (was Re: cvs commit: src/lib/libc/gen ...) Message-ID: <20030501160155.GB55078@nagual.pp.ru> In-Reply-To: <Pine.GSO.4.10.10305011143400.11732-100000@pcnet1.pcnet.com> References: <20030501154139.GA54878@nagual.pp.ru> <Pine.GSO.4.10.10305011143400.11732-100000@pcnet1.pcnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030501160155.GB55078>