Date: Mon, 21 Aug 2000 12:50:24 -0400 (EDT) From: Daniel Eischen <eischen@vigrid.com> To: "Jacques A. Vidrine" <n@nectar.com> Cc: freebsd-arch@FreeBSD.ORG Subject: Re: Is it time yet? [was Re: Weak symbols] Message-ID: <Pine.SUN.3.91.1000821124253.24400A-100000@pcnet1.pcnet.com> In-Reply-To: <20000821105919.A25903@hamlet.nectar.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 21 Aug 2000, Jacques A. Vidrine wrote: > On Sat, Oct 16, 1999 at 08:07:23AM +1000, John Birrell wrote: > > A weak symbol is like an alias for another (strong) symbol. The linker > > will link to strong symbols first, then, for any unresolved references, > > it will try to resolve against the weak symbols before going on to > > the next library. Weak symbols are a good way to hide things in order > > to stop polluting the name space. But they can cause problems too. > > > > Our use of weak symbols in libc is incomplete. Although syscalls like > > read() have _read() as the strong symbol and read() as the weak one, > > we continue to call read() in other areas of libc. This means that > > a user can create their own read() function and they won't get a clash > > when they link against libc, but other functions in libc that really > > want to call the _read() syscall will call the user's read() function > > instead. That's broken. We really need to change libc in the way that > > NetBSD did with their namespace.h stuff. This ensures that the internals > > of libc call the hidden names, not the weakly exported ones. > > Any compelling reason not do to this? I'm willing to do the (apparently > grunt) work. I would use the same approach as NetBSD, basically: > > 1) namespace.h would use the preprocessor to rename our public symbols > so that they begin with an underscore, e.g. > > #define warnx _warnx > > 2) add __weak_alias for each symbol in the files in which they are > defined, e.g. > > __weak_alias(warnx, _warnx); > > in err.c > > I'd like to hear if anyone has better suggestions, though. I think this is a good idea, but should we also fix our internal calls of foo() to _foo()? You also have to think about the threads library, both current and future. We have to be able to build libc_r, and want in the future to be able to build libpthread that can be linked with libc. -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.SUN.3.91.1000821124253.24400A-100000>