Date: Fri, 19 Jan 2001 19:38:00 -0500 From: Daniel Eischen <eischen@vigrid.com> To: arch@freebsd.org Cc: current@freebsd.org Subject: Request For Review: libc/libc_r changes to allow -lc_r Message-ID: <3A68DDE8.7F8D3C51@vigrid.com>
next in thread | raw e-mail | index | archive | help
[ Followups to -arch only please ] I've got some changes to libc and libc_r that I'd like reviewed. These changes eliminate the _THREAD_SAFE macro and allow a libc and libc_r that can be linked together via -lc_r. This also means that -pthread and -D_THREAD_SAFE can be deprecated. Note that libc_r could be now be renamed libpthread, but I would like to reserve that for KSE Project development where we might want to have both libraries around while libpthread (using KSEs) is being developed. The diffs are posted at: http://people.freebsd.org/~deischen/libc.diffs http://people.freebsd.org/~deischen/libc_r.diffs The libc diffs include src/include, src/lib/libc, as well as src/usr.sbin/pppctl (our only threaded app) changes, whereas the libc_r diffs are just those changes to src/lib/libc_r. I've tested these changes with ACE, but still have other testing that I'll be doing over the weekend. The patches have also survived a buildworld, but the installworld will have to wait for this weekend. If you try these patches make sure you save a copy of libc.so.5 just in case... And BTW, many thanks to John Polstra for explaining some of the issues involved with linking :-) Overview of the changes ----------------------- For those not familiar with our current libc_r, it is currently built to include a thread-safe libc as well as the POSIX threads routines. On the other hand, libc is built to be non-thread safe. This differs from other OSs and from what POSIX mandates and means that we require non-standard hacks like the linker option -pthread (which links to libc_r and prevents linking to libc). System calls that need to be wrapped (HIDDEN_SYSCALLS) are now defined in libc/Makefile instead of libc_r/Makefile. This means that libc now contains: _thread_sys_foo - actual syscall _foo - weak definition to _thread_sys_foo foo - weak definition to _thread_sys_foo I've changed all the instances of foo() to _foo() in libc for those hidden system calls. Anyone modifying or adding to libc will have to be careful to use the same conventions. In order to define the prototypes for _foo(), we introduce namespace.h and un-namespace.h. BDE suggested this as a way to define the prototypes for the hidden system calls. Use them as follows: #include "namespace.h" #include <unistd.h> /* Other standard includes... */ #include "un-namespace.h" /* * DB contains the member 'close' which is defined to * _close if included before un-namespace.h */ #include <db.h> /* Other local includes... */ int somelibcfunc(int fd, void *buf, size_t len) { ... ret = (int)_read(fd, buf, len); ... return (ret); } Including namespace.h will define those hidden system calls used within libc from foo to _foo; un-namespace.h will undefine them. A few others are defined as well, such as _pthread_mutex_lock and friends. This allows libc_r to provide replacement functions for them if it is also linked in. One note about lib/libc/stdio/mktemp.c. This file really wants to use namespace.h but can't because it is used in building part of the C compiler (or something like that; the error has long since scrolled off my window). There are basically only two changes to libc_r. One is to implement the pthread_foo() functions as _pthread_foo() and make pthread_foo a weak definition to _pthread_foo. This allows an application to have it's own pthread_foo(). I noticed Solaris does this to libpthread as well as to libc. The other change to libc_r is to eliminate references to the global _thread_run and replace them with a function call to get the currently running thread (which will be needed for the KSE project). Yes, I could do something like errno, but that wouldn't encourage getting the running thread once and caching it. Comments welcome, -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3A68DDE8.7F8D3C51>