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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Clemens Kolbitsch wrote:
> Is there a specific reason for not using
> 
> movb	PSHARED(%edi), %ecx

Yes, movb doesn't fill in the right value.  But it should
have
consistently be movzbl.  This was used in some places but
not
everywhere.  It's fixed now.

- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧
Mountain View, CA ❖
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org


iEYEARECAAYFAkgmhxYACgkQ2ijCOnn/RHS8xQCeLiQZeHzdANlLAEvb8paB
jP/4
1foAn2+QKcCvDU1d0Ut1t+AznvFjRnMB
=aZgs
-----END PGP SIGNATURE-----