[PATCH] Add BeOS support for libstdc++-v3

[Daniel Berlin]

On 21 Nov 2000, Gabriel Dos Reis wrote:

> Daniel Berlin <dan@www.cgsoftware.com> writes:
> 
> | [1  <text/plain; US-ASCII (7bit)>]
> | This patch and new file add support for BeOS (including multithreaded
> | support) to libstdc++.
> | 
> | Unfortunately, the gen-num-limits patch is necessary, or else we go into
> | a 100% cpu loop due to some oddness in BeOS signal handling.
> | 
> | threads-beos.h goes in config.
> | I didn't include a regenerated configure in the patch.
> 
> OK.  The tools needed to regenerate them can be found on the libstdc++
> ftp site.
> 
> [...]
> 
> | Index: acinclude.m4
> 
> This is OK.
> 
> [...]
> 
> | Index: aclocal.m4
> 
> [...]
> 
> OK.
> 
> | Index: configure.target
> 
> [...]
> 
> OK.
> 
> | Index: mknumeric_limits
> | ===================================================================
> | RCS file: /cvs/gcc/egcs/libstdc++-v3/mknumeric_limits,v
> | retrieving revision 1.4
> | diff -c -3 -p -r1.4 mknumeric_limits
> | *** mknumeric_limits	2000/11/04 03:00:10	1.4
> | --- mknumeric_limits	2000/11/18 15:31:43
> | *************** case `uname` in
> | *** 21,26 ****
> | --- 21,28 ----
> |   		LDFLAGS='-nodefaultlibs -lgcc -lc' ;;
> |   	esac
> |   	;;
> | +     BeOS*)
> | +     	LDFLAGS='-nodefaultlibs -lgcc -lroot' ;;
> 
> Could there be any note explaining the purpose of -lroot?
> 
Sure.
It's our -lc.
:)

> [...]
> 
> | Index: include/bits/stl_config.h
> 
> [...]
> 
> OK.
> 
> [...]
> 
> | Index: include/bits/stl_threads.h
> | ===================================================================
> | RCS file: /cvs/gcc/egcs/libstdc++-v3/include/bits/stl_threads.h,v
> | retrieving revision 1.1
> | diff -c -3 -p -r1.1 stl_threads.h
> | *** stl_threads.h	2000/10/05 11:27:01	1.1
> | --- stl_threads.h	2000/11/18 15:31:43
> | ***************
> | *** 34,39 ****
> | --- 34,41 ----
> |   #include <synch.h>
> |   #elif defined(__STL_WIN32THREADS)
> |   #include <windows.h>
> | + #elif defined(__STL_BEOSTHREADS)
> | + #include <bits/libc-lock.h>
> |   #endif
> |   
> |   __STL_BEGIN_NAMESPACE
> | *************** struct _Refcount_Base
> | *** 56,61 ****
> | --- 58,65 ----
> |     // The type _RC_t
> |   # ifdef __STL_WIN32THREADS
> |     typedef long _RC_t;
> | + # elif  __STL_BEOSTHREADS
> | +   typedef unsigned long _RC_t;
> |   # else
> |     typedef size_t _RC_t;
> |   #endif
> 
> OK.
> 
> | *************** struct _Refcount_Base
> | *** 107,112 ****
> | --- 111,124 ----
> |       mutex_unlock(&_M_ref_count_lock);
> |       return __tmp;
> |     }
> | + # elif defined(__STL_BEOSTHREADS)
> | +   void _M_incr() {
> | +     atomic_add(&_M_ref_count, 1);
> | +   }
> | +   _RC_t _M_decr() {
> | +     atomic_add(&_M_ref_count, -1);
> | +     return _M_ref_count;
> | +   }
> 
> Formatting remarks: This should read
> 
> 	void
> 	_M_incr()
> 	{ /* ... */ }
> 
> 	_RC_t
> 	_M_decr()
> 	{
> 	   // ...
> 	}
> 
> Please, refer tp the C++STYLE notes.
> 
> |   # else  /* No threads */
> |     void _M_incr() { ++_M_ref_count; }
> |     _RC_t _M_decr() { return --_M_ref_count; }
> | *************** struct _Refcount_Base
> | *** 129,134 ****
> | --- 141,159 ----
> |       inline unsigned long _Atomic_swap(unsigned long * __p, unsigned long __q) {
> |           return (unsigned long) InterlockedExchange((LPLONG)__p, (LONG)__q);
> |       }
> | + # elif defined(__STL_BEOSTHREADS)
> | +     inline unsigned long _Atomic_swap(unsigned long *p, unsigned long newval) {
> 
> Same comments here.
> 
> 
> | + {
> | +   unsigned long retval;
> | +   long int readval;
> | +   __asm__ ("lock");
> | +   retval = *p;
> | + 
> | +   __asm__ __volatile__ ("lock; xchgl %3, %1; sete %0"
> | +                         : "=q" (ret), "=m" (*p), "=a" (readval)
> | +                         : "r" (newval), "m" (*p));
> | +   return retval;
> | + }
> |   # elif defined(__STL_PTHREADS)
> |       // We use a template here only to get a unique initialized instance.
> |       template<int __dummy>
> | *************** struct _STL_mutex_lock
> | *** 325,330 ****
> | --- 350,360 ----
> |     void _M_initialize()   { mutex_init(&_M_lock, USYNC_THREAD, 0); }
> |     void _M_acquire_lock() { mutex_lock(&_M_lock); }
> |     void _M_release_lock() { mutex_unlock(&_M_lock); }
> | + #elif defined(__STL_BEOSTHREADS)
> | +   sem_id _M_lock;
> | +   void _M_initialize()   { _M_lock = create_sem(1, "STL semaphore"); }
> | +   void _M_acquire_lock() { acquire_sem(_M_lock);  }
> | +   void _M_release_lock() { release_sem(_M_lock);  }
> 
> Ditto.
> 
> Aprt from that, it is OK.
> 
> [...]
> 
> | Index: libio/libioP.h
> | ===================================================================
> 
> OK -- but the libio bits won't properly work; that is not your fault.
> 

I know, it's actually something I noticed in V2. Because libroot is a
bastardized glibc, it doesn't identify itself as GLIBC, but a lot of
functionality from glibc is there, including the locking bits. Not enough
that you can get away with saying it's GLIBC 2.1, too much thinks that
means we have things we don't.
It's a serious pain in the ass on BeOS.

 > [...]
> 
> | Index: libmath/mathconf.h
> | ===================================================================
> | RCS file: /cvs/gcc/egcs/libstdc++-v3/libmath/mathconf.h,v
> 
> This is OK.  
> 
> At some point I would completely remove this dependency.
> 
I'm working on it, trying to see why it passes that test. The reason the
dependency is there is because complex.h on BeOS expects to be included in
C++ files, and has classes and whatnot in it, and mathconf.h is included
in C files.

 > [...] > 
> | Index: src/gen-num-limits.cc
> | ===================================================================
> 
> [...]
> 
> | + #else
> | +     const char *p = "false";
> | + #endif
> 
> Is this so because 1/0 need cause interruption or just because there
> is no way to test the various trapping?

They cause an infinite loop using 100% cpu.
The first few work okay, then it goes to hell. 
It's on the longjmp call, which is very puzzling.
I want to say it's longjmping back to the longjmp call, but i can't
remember the exact sequence.
It doesn't crash, it just goes around and around again, but never gets to
an invalid place.

Can't tell if it's a signal interaction, or what.

> Otherwise, it is OK for a temporary workaround.

Okey, i'm really trying to figure out a better way around it.
> 
> [...]
> 
> 
> -- Gaby
> CodeSourcery, LLC                       http://www.codesourcery.com
>