This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
pthread_rwlock_unlock.S unaligned access to PSHARED
- From: Clemens Kolbitsch <clemens dot kol at gmx dot at>
- To: libc-alpha at sourceware dot org
- Date: Mon, 21 Jan 2008 14:48:56 +0100
- Subject: pthread_rwlock_unlock.S unaligned access to PSHARED
Hi!
I just took a look at my glibc-2.7 source (compiling it for a kubuntu linux,
x86 / i486) - more precisely at the file
nptl/dysdeps/unix/sysv/linux/i386/i486/pthread_rwlock_unlock.S
and have a question concerning line 172 in the function
__pthread_rwlock_unlock:...
/* Get the lock. */
movl $1, %edx
xorl %eax, %eax
LOCK
#if MUTEX == 0
cmpxchgl %edx, (%edi)
#else
cmpxchgl %edx, MUTEX(%edi)
#endif
jnz 1f
2:
...
1:
#if MUTEX == 0
movl %edi, %edx
#else
leal MUTEX(%edi), %edx
#endif
movl PSHARED(%edi), %ecx # <<<< line 172
call __lll_lock_wait
jmp 2b
The edi-register points to the rw-lock that should be unlocked, which has the
structure (in case someone hasn't looked at the struct for quite a
while ;-) ):
typedef union
{
struct
{
int __lock;
unsigned int __nr_readers;
unsigned int __readers_wakeup;
unsigned int __writer_wakeup;
unsigned int __nr_readers_queued;
unsigned int __nr_writers_queued;
/* FLAGS must stay at this position in the structure to maintain
binary compatibility. */
unsigned char __flags;
unsigned char __shared;
unsigned char __pad1;
unsigned char __pad2;
int __writer;
} __data;
char __size[__SIZEOF_PTHREAD_RWLOCK_T];
long int __align;
} pthread_rwlock_t;
Therefor, edi is dereferenced as
mov 0x19(%edi),%ecx
and since 0x19 is unaligned, ecx will have the value of __shared (that's what
we want), __pad[12] (always 0) and the LSB of __writer (which is definitelly
NOT what we want)!!!!
Is there a specific reason for not using
movb PSHARED(%edi), %ecx
or is that simply a bug that might not have any effects jet?
I know, this is not the millennium bug, but I'm still curious ;-)
Clemens