Jim Ingham 10ebffa48a Don't expose the pthread_mutex_t underlying the Mutex & Mutex::Locker classes. ... No one was using it and Locker(pthread_mutex_t *) immediately asserts for pthread_mutex_t's that don't come from a Mutex anyway. Rather than try to make that work, we should maintain the Mutex abstraction and not pass around the platform implementation... Make Mutex::Locker::Lock take a Mutex & or a Mutex *, and remove the constructor taking a pthread_mutex_t *. You no longer need to call Mutex::GetMutex to pass your mutex to a Locker (you can't in fact, since I made it private.) llvm-svn: 156221		2012-05-04 23:02:50 +00:00
..
FreeBSD	Patch from Viktor Kutuzov <vkutuzov@accesssoftek.com>:	2012-04-14 00:54:42 +00:00
Linux	Remove the GetSequenceMutex timeout that isn't being used in the GDB remote plug-in.	2012-04-12 19:04:34 +00:00
MacOSX-Kernel	Don't expose the pthread_mutex_t underlying the Mutex & Mutex::Locker classes.	2012-05-04 23:02:50 +00:00
POSIX	Patch from Viktor Kutuzov <vkutuzov@accesssoftek.com>:	2012-04-14 00:54:42 +00:00
Utility	Add missing watchpoint stop info creation logic for arm on the debugger side.	2012-03-21 18:28:25 +00:00
gdb-remote	Don't expose the pthread_mutex_t underlying the Mutex & Mutex::Locker classes.	2012-05-04 23:02:50 +00:00
mach-core	Trying to solve our disappearing thread issues by making thread list updates safer.	2012-04-10 00:18:59 +00:00