This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
Re: [PATCH] Avoid redefinitions in libc/include/sys/types.h in case __rtems__ is defined
On 02/28/2011 12:40 PM, Corinna Vinschen wrote:
> On Feb 24 13:44, Sebastian Huber wrote:
>> Hello,
>>
>> currently we have in Newlib for RTEMS:
>>
>> sys/types.h:393:0: warning: "PTHREAD_MUTEX_NORMAL" redefined
>> sys/types.h:310:0: note: this is the location of the previous definition
>> sys/types.h:394:0: warning: "PTHREAD_MUTEX_RECURSIVE" redefined
>> sys/types.h:325:0: note: this is the location of the previous definition
>> sys/types.h:396:0: warning: "PTHREAD_MUTEX_DEFAULT" redefined
>> sys/types.h:332:0: note: this is the location of the previous definition
>>
>> In <sys/features.h> we have
>>
>> #ifdef __rtems__
>> ...
>> #define _UNIX98_THREAD_MUTEX_ATTRIBUTES 1
>> ...
>> #endif
>>
>> We include <sys/features.h> in <sys/types.h> before the PTHREAD_MUTEX_*
>> defines. The _UNIX98_THREAD_MUTEX_ATTRIBUTES is also used in the RTEMS sources
>> to enable the attribute specific code.
>>
>> Why do we have different numeric values for the PTHREAD_MUTEX_* defines?
>
> I'm not sure whom you're asking.
>
> To me, this change looks a bit suspicious. If _UNIX98_THREAD_MUTEX_ATTRIBUTES
> was defined for RTEMS and XMK for a while, the second set of definition of
> the PTHREAD_MUTEX values have ruled for a long time, right?
Yes, it is there since:
2008-09-25 Raphael Derossa Pereira <raphaelpereira@gmail.com>
* libc/include/sys/types.h[_UNIX98_THREAD_MUTEX_ATTRIBUTES]: Add
new mutex type values.
(pthread_mutexattr_t)[_UNIX98_THREAD_MUTEX_ATTRIBUTES]: Add type
field.
http://sourceware.redhat.com/cgi-bin/cvsweb.cgi/src/newlib/libc/include/sys/types.h.diff?r1=1.28&r2=1.29&cvsroot=src&f=h
> So what your
> patch is doing is to replace the so far used values with the overruled values
> from earlier in the file. Doesn't that break backward compatibility?
You are right. The earlier defines are from:
2009-06-17 Michael Eager <eager@eagercon.com>
* libc/include/pthread.h: Support XMK (Xilinx) BSP, add RTEMS to
PTHREAD_MUTEX_NORMAL.
* libc/include/sys/types.h: Same.
http://sourceware.redhat.com/cgi-bin/cvsweb.cgi/src/newlib/libc/include/sys/types.h.diff?r1=1.29&r2=1.30&cvsroot=src&f=h
http://sourceware.redhat.com/cgi-bin/cvsweb.cgi/src/newlib/libc/include/sys/config.h.diff?r1=1.53&r2=1.54&cvsroot=src&f=h
RTEMS defines _UNIX98_THREAD_MUTEX_ATTRIBUTES in <sys/features.h> and XMK
defines it in <sys/config.h>. Both header files will be included in <sys/types.h>.
So hopefully the attached patch is now correct.
--
Sebastian Huber, embedded brains GmbH
Address : Obere Lagerstr. 30, D-82178 Puchheim, Germany
Phone : +49 89 18 90 80 79-6
Fax : +49 89 18 90 80 79-9
E-Mail : sebastian.huber@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschÃftliche Mitteilung im Sinne des EHUG.
Index: ./libc/include/sys/types.h
===================================================================
RCS file: /cvs/src/src/newlib/libc/include/sys/types.h,v
retrieving revision 1.35
diff -u -r1.35 types.h
--- ./libc/include/sys/types.h 15 Jan 2011 09:26:16 -0000 1.35
+++ ./libc/include/sys/types.h 28 Feb 2011 12:27:36 -0000
@@ -301,39 +301,6 @@
#define PTHREAD_CREATE_DETACHED 0
#define PTHREAD_CREATE_JOINABLE 1
-#if defined(__XMK__) || defined(__rtems__)
-/* The following defines are part of the X/Open System Interface (XSI). */
-
-/* This type of mutex does not detect deadlock. A thread attempting to relock this mutex without first unlocking
- * it shall deadlock. Attempting to unlock a mutex locked by a different thread results in undefined behavior.
- * Attempting to unlock an unlocked mutex results in undefined behavior.
- */
-#define PTHREAD_MUTEX_NORMAL 1
-
-/*
- * This type of mutex provides error checking. A thread attempting to relock this mutex without first unlocking
- * it shall return with an error. A thread attempting to unlock a mutex which another thread has locked shall return
- * with an error. A thread attempting to unlock an unlocked mutex shall return with an error.
- */
-#define PTHREAD_MUTEX_ERRORCHECK 2
-
-/* A thread attempting to relock this mutex without first unlocking it shall succeed in locking the mutex.
- * The relocking deadlock which can occur with mutexes of type PTHREAD_MUTEX_NORMAL cannot occur with this type of mutex.
- * Multiple locks of this mutex shall require the same number of unlocks to release the mutex before another thread can
- * acquire the mutex. A thread attempting to unlock a mutex which another thread has locked shall return with an error.
- * A thread attempting to unlock an unlocked mutex shall return with an error.
- */
-#define PTHREAD_MUTEX_RECURSIVE 3
-
-/* Attempting to recursively lock a mutex of this type results in undefined behavior. Attempting to unlock a
- * mutex of this type which was not locked by the calling thread results in undefined behavior. Attempting to
- * unlock a mutex of this type which is not locked results in undefined behavior. An implementation may map this
- * mutex to one of the other mutex types.
- */
-#define PTHREAD_MUTEX_DEFAULT 4
-
-#endif /* defined(__XMK__) || defined(__rtems__) */
-
#if defined(__XMK__)
typedef struct pthread_attr_s {
int contentionscope;