Date: Mon, 21 Aug 2000 20:46:44 -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.1000821200529.26995A-100000@pcnet1.pcnet.com> In-Reply-To: <20000821175359.C26324@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 Mon, Aug 21, 2000 at 12:50:24PM -0400, Daniel Eischen wrote: > > I think this is a good idea, but should we also fix our internal > > calls of foo() to _foo()? > > Yes, if `foo' has external linkage. I agree, but this may cause some problems for a future libpthread. > > > 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. > > Can you go into more detail here? Is there something special to do for > libc_r? When building libc_r, _read() is a weak symbol for _thread_sys_read(), and _thread_sys_read() is the actual system call. The same is true for most other blocking calls that the threads library wants to wrap. There are also cases where you have to use strong references; I don't know exactly why, but see: http://www.FreeBSD.org/cgi/cvsweb.cgi/src/lib/libc_r/uthread/uthread_pipe.c When we want to (someday) build libpthread, it will have to be linkable with libc. If we wanted the threads library to be able to catch internal calls to _read(), then _read() can't be the actual system call. This should not be a problem with a "scheduler activations"-based threads library (we shouldn't have to wrap potentially blocking syscalls). I'd like to make this assumption, but wouldn't rule out the possibility of having to override a few library/system calls from libpthread. -- 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.1000821200529.26995A-100000>