Re: pthread locking code - C vs. ASM

[Gilles Carry <Gilles dot Carry at bull dot net>]

Mike Frysinger wrote:
> On Saturday 19 January 2008, Clemens Kolbitsch wrote:
>
> > Why are some (e.g. locking) functions implemented twice -- once in C and
> > once in assembler?
>
>
> why is anything written in assembler ?  for optimization.
>
>
> > Is the C code used to get an asselber starting point 
> > which is then optimized and saved into a second file?
>
>
> that is one way of looking at it.  you write the generic C version for 
> everyone to use and if there's enough interest, re-implement it for a 
> specific operating system/architecture in assembly.  if an appropriate 
> optimized version exists in the source tree, glibc will use that, otherwise 
> it'll default to the generic C version.
>
>
> > For example pthread_rwlock_unlock is implemented in
> > source/nptl/sysdeps/unix/sysv/linux/i386/i486/pthread_rwlock_unlock.S
> > and
> > source/nptl/pthread_rwlock_unlock.c
> >
> > If I modify the asm code only, is there a chance that some script (e.g.
> > during make clean && make) will overwrite my changes or is the ASM code the
> > correct place to edit things (otherwise I don't see my modifications being
> > linked into the binary...)?
>
>
> no, that is not how the build system works.  pretty much all assembly code in 
> glibc is hand written and not autogenerated.  glibc uses search paths 
> depending on your operating system, target architecture, and specific cpu to 
> figure out which implementation to use.
>
> if your target operating system is linux, the target architecture is i386, and 
> the specific cpu implementation is i486, then 
> nptl/sysdeps/unix/sysv/linux/i386/i486/pthread_rwlock_unlock.S is the file to 
> modify.  if your target is {linux,i386,i686}, then you should actually look 
> at nptl/sysdeps/unix/sysv/linux/i386/i686/pthread_rwlock_unlock.S.
> -mike

Is asm code supposed to do exactly the same as C code?
I recently had a case when I wanted to modify pthread_cond_signal.c and it did not compile
because of unexisting syscall macros.
Should C code be the reference? Should asm be modified only when we are sure C is ok?
It is a problem when people change asm code without updating the underlying C files.

-gilles