From 9ae3ef111bcdcfb6d4ca3a708791dde9a33eb24f Mon Sep 17 00:00:00 2001 From: David Leonard Date: Tue, 22 Dec 1998 22:30:36 +0000 Subject: update --- lib/libc_r/TODO | 36 +++++++++--------------------------- 1 file changed, 9 insertions(+), 27 deletions(-) (limited to 'lib/libc_r') diff --git a/lib/libc_r/TODO b/lib/libc_r/TODO index b643c668900..75ce8fb8789 100644 --- a/lib/libc_r/TODO +++ b/lib/libc_r/TODO @@ -1,40 +1,21 @@ This is a list of things that still need to be done: -* Fix the totally bogus _atomic_lock in arch/mips. - This is a nightmare because you really need to incur a ctxt switch - for pmaxen. R4000 has some instructions to do an atomic test-and-set - but not mips1. fuck fuck fuck. the ctx switch has to be sigsetmask - * Add thread stuff to the other archs in libc/arch/; ie change some usages of ENTRY to SYSENTRY in some .S files and add - the new macros to their SYS.h. Only the i386 arch is working. - -* Finish/verify the md stuff for setjmp and atomic_lock for sparc and - alpha. Boy do they look dodgy. + the new macros to their SYS.h. * Find a better way of doing the _sys_aliases stuff; ideally by - using the linker. jmp's (current implementation) are ugly, but + using the linker. jmp's and branches (current implementation) are ugly, but I don't want to have to hack ../libc/sys/Makefile.inc just to partition the syscalls into wrapped and non-wrapped. The `.set' assembler directive just doesn't work as I thought it would. -* Fix the bug where _thread_init() isn't called when libc_r.so is used - instead of libc_r.a ... some kind of shlib common problem? may - need to use crt0 instead? __CTOR_LIST__ is just not being updated by ld. - Frankly this one is driving me nuts. Maybe is wrong. - This varies on different architectures and exec format. - -* Test the objective-C compiler to see if it can use threads. - Really this shows up a nasty problem with needing to say -threads - whenever you want to use threads. Ideally, linking with -lc_r library - would override -lc; but the _POSIX_THREADS define would alter - some optimisations done in ... What to do!?! FreeBSD looks - like they are going to have an always-threaded libc with optimisations - for the 1-thread case and use weak symbols to override functions when - someone uses -lc_r. Do we have weak symbols everywhere? I wonder - what the performance hit is if #define LOCK() if(nthreads>1){lock();} - is used... need to profile this. +* Test that thread_init is automatically called on every arch, regardless + of whether the exe is statically linked or not. + +* Alter the objective-C compiler to see if it can use threads. + It looks like the easy way is to just define CC='cc -pthread'. * Find all the static buffers in libc and make them per-thread. This is not absolutely necessary but incurs no penalty for single-threaded @@ -59,5 +40,6 @@ This is a list of things that still need to be done: its in the database routines mostly. We will need to rip their code. * Figure out what to do with the configuration system variables (_SC_*) + that are defined by POSIX 1003.1c -$OpenBSD: TODO,v 1.3 1998/11/20 11:18:57 d Exp $ +$OpenBSD: TODO,v 1.4 1998/12/22 22:30:35 d Exp $ -- cgit v1.2.3