From owner-freebsd-arch Sun Jan 21 13:33:21 2001 Delivered-To: freebsd-arch@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 2430B37B400 for ; Sun, 21 Jan 2001 13:33:04 -0800 (PST) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id QAA15453; Sun, 21 Jan 2001 16:32:39 -0500 (EST) Date: Sun, 21 Jan 2001 16:32:39 -0500 (EST) From: Daniel Eischen To: Warner Losh Cc: "Jacques A. Vidrine" , arch@FreeBSD.ORG Subject: Re: Request For Review: libc/libc_r changes to allow -lc_r In-Reply-To: <200101212030.f0LKUV901434@harmony.village.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 21 Jan 2001, Warner Losh wrote: > In message Daniel Eischen writes: > : Well, we don't seem to be following that right now, but I'll adhere to > : that in anything I add. So how about instead of using _thread_sys_foo, > : we use __sys_foo: > : > : __sys_foo - actual system call > : _foo - weak definition to __sys_foo > : foo - weak definition to __sys_foo > > Good, but would it be easy to do __foo rather than _foo? Is there a > reason why _foo would be desired? Oops, sorry, I missed the second question. You need _foo to be used within libc, so that when libc_r/libpthread is linked in, it can provide a replacement function for it. We also need to determine if the function is a cancellation point or not, so if you just had foo and __sys_foo, libc_r/libpthread would have no way of knowing if foo was called from within libc or from the user application. The former is not a cancellation point, while the latter is (if foo is read for example). -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message