From owner-freebsd-questions@FreeBSD.ORG Fri Aug 3 09:55:30 2007 Return-Path: Delivered-To: questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AABB316A420; Fri, 3 Aug 2007 09:55:30 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from relay02.kiev.sovam.com (relay02.kiev.sovam.com [62.64.120.197]) by mx1.freebsd.org (Postfix) with ESMTP id 8D21F13C48D; Fri, 3 Aug 2007 09:55:28 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from [89.162.146.170] (helo=skuns.kiev.zoral.com.ua) by relay02.kiev.sovam.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1IGt6H-000LUx-Gh; Fri, 03 Aug 2007 12:05:46 +0300 Received: from deviant.kiev.zoral.com.ua (root@[10.1.1.148]) by skuns.kiev.zoral.com.ua (8.14.1/8.14.1) with ESMTP id l7395VoW039296 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 3 Aug 2007 12:05:31 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.1/8.14.1) with ESMTP id l7395VKv035835; Fri, 3 Aug 2007 12:05:31 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.1/8.14.1/Submit) id l7395Usa035834; Fri, 3 Aug 2007 12:05:30 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 3 Aug 2007 12:05:30 +0300 From: Kostik Belousov To: Jin Guojun Message-ID: <20070803090530.GH2738@deviant.kiev.zoral.com.ua> References: <46B245D5.1050606@george.lbl.gov> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="zq44+AAfm4giZpo5" Content-Disposition: inline In-Reply-To: <46B245D5.1050606@george.lbl.gov> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.91.1, clamav-milter version 0.91.1 on skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.2.1 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on skuns.kiev.zoral.com.ua X-Scanner-Signature: b46f4584ea35a5bfe65e3be67b2b2352 X-DrWeb-checked: yes X-SpamTest-Envelope-From: kostikbel@gmail.com X-SpamTest-Group-ID: 00000000 X-SpamTest-Header: Not Detected X-SpamTest-Info: Profiles 1330 [August 2 2007] X-SpamTest-Info: helo_type=3 X-SpamTest-Method: none X-SpamTest-Rate: 0 X-SpamTest-Status: Not detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0255], KAS30/Release Cc: threads@freebsd.org, questions@freebsd.org Subject: Re: how sys_select, sys_fork, ... are defined for thread libraries? X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2007 09:55:30 -0000 --zq44+AAfm4giZpo5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Aug 02, 2007 at 02:00:05PM -0700, Jin Guojun wrote: > I am trying to understand how these __sys_xxx functions are defined for= =20 > thread libraries. > Following string search tells that all thread libraries are using these= =20 > __sys_xxx functions, > for example, __sys_select(). However, the search also shows that these=20 > functions are not defined anywhere in the entire source tree. >=20 > /usr/src: findstring sys_select "*.[hcS]" > total files=3D 21687 : pattern=3D sys_select rootdir=3D /usr/src > regular mode: Thu Aug 2 13:31:40 PDT 2007 > ./lib/libc_r/uthread/uthread_fork.c > 91: * __sys_select: >=20 > ./lib/libpthread/thread/thr_private.h > 1264:int __sys_select(int, fd_set *, fd_set *, fd_set *, struct=20 > timeval *); >=20 > ./lib/libpthread/thread/thr_select.c > 61: ret =3D __sys_select(numfds, readfds, writefds, exceptfds= ,=20 > timeout); >=20 > ./lib/libthr/thread/thr_private.h > 805:int __sys_select(int, fd_set *, fd_set *, fd_set *, struct=20 > timeval *); >=20 > ./lib/libthr/thread/thr_syscalls.c > 435: ret =3D __sys_select(numfds, readfds, writefds, exceptfds, timeou= t); >=20 >=20 > By searching the usr/lib objects, I found them in libc, but they are not= =20 > in libc source tree. > Can someone shed some light on how these system calls are built into=20 > libc and what is the > different between standard syscall APIs and these __sys_syscall APIs, > e.g., __sys_read() vs. read(), etc. >=20 > Thanks, >=20 > -Jin >=20 >=20 > nm /usr/lib/libc.a | grep __sys_ > 00000008 T __sys_sigreturn > 00000008 T __sys_setlogin > 00000008 T __sys_reboot > ... snapped > 00000008 T __sys_kse_release > 00000008 T __sys_kse_thr_interrupt > 00000008 T __sys_kse_create > 00000008 T __sys_kse_wakeup > ... skipped > 00000008 T __sys_getdtablesize > 00000008 T __sys_select > 00000008 T __sys_ioctl > 00000008 T __sys_close > 00000008 T __sys_write > 00000008 T __sys_read > 00000008 T __sys___syscall The C standard specifies that namespace of identifiers starting with __ or _ is reserved for implementation. On the other hand, C standard allows for the programs to use any symbol not reserved by standard. The thread libraries (and libc) shall internally use the "right" implementation of syscalls, as opposed to some symbol supplied by user binary. To achieve this, for each syscall x, libc defines the normal symbol __sys_x, and two weak symbols _x and x. See, for instance, the file lib/libc/select.S from the obj directory, and lib/libc/i386/SYS.h for corresponding include file. Definition of weak symbols is provided by ELF specification. Simplyfing, weakness of the symbol mean that it is used only unless somebody provides the same normal symbol. Normal symbols from text segment are marked by "T" in nm output, and weak symbols has "t" mark. --zq44+AAfm4giZpo5 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGsu/ZC3+MBN1Mb4gRAvOlAJ9DDfdILBWswe7L9ul+iIwVGWpzJQCdF6JN UWaFyV83spPuFSF9nMJqUqw= =z14i -----END PGP SIGNATURE----- --zq44+AAfm4giZpo5--