Contributing to the glibc Project

Contributing to the glibc Project

[Nam-goo Lee]

Hi.

I'd like to contribute to the glibc project.
I've checked the jobs listed on the PROJECT file.
I became interested on the job number [8] - assembly programming.
I'd like to work on the ARM architecture.

Looking at the codes under the /sysdeps/arm directory, it seems there
is only one assembly code for the string handling functions: strlen.S.
I'd like to contribute to the project by committing assembly codes of
the string handling functions for the ARM architecture.

If this job is available, it'll be my first contribution to an
open-source project, and I'm really excited and looking forward to
joining the glibc developer community.

Best regards,
Nam-goo Lee

Re: Contributing to the glibc Project

[Adhemerval Zanella]

Hi Nam-goo Lee,

Thanks for taking interest in working with glibc. At this link [1]
you will find a descriptive checklist of what is required and
suggested to do before starting send patches to libc-alpha.  Pay
special attention at item '9. FSF copyright Assignment' since
without it we can't take your contributions.

Regarding your specific interest, in fact there are multiple
string implementation for ARM:

$ find sysdeps/arm/ -iname 'str*' -o -iname 'mem*'
sysdeps/arm/armv6t2/memchr.S
sysdeps/arm/armv6t2/strlen.S
sysdeps/arm/memusage.h
sysdeps/arm/memcpy.S
sysdeps/arm/memset.S
sysdeps/arm/memmove.S
sysdeps/arm/strlen.S
sysdeps/arm/armv7/multiarch/memcpy_impl.S
sysdeps/arm/armv7/multiarch/memcpy.S
sysdeps/arm/armv7/multiarch/memcpy_neon.S
sysdeps/arm/armv7/multiarch/memcpy_vfp.S
sysdeps/arm/armv7/strcmp.S
sysdeps/arm/armv6/strcpy.S
sysdeps/arm/armv6/strchr.S
sysdeps/arm/armv6/strlen.S
sysdeps/arm/armv6/strrchr.S

For strlen we do have an armv6, armv6 thumb2, and the default one
which should work on minimum supported arm (armv5?).

Also note that for armv7+ we use ifunc to select of different
implementation for memcpy. One possible work I would suggest you
and use the memcpy* for amrv7 and create also a multiarch memmove
implementation based on current armv7 strategies, since armv7 
still uses the default memmove.S implementation.

[1] https://sourceware.org/glibc/wiki/Contribution%20checklist

On 13/10/2016 02:37, Nam-goo Lee wrote:
> Hi.
> 
> I'd like to contribute to the glibc project.
> I've checked the jobs listed on the PROJECT file.
> I became interested on the job number [8] - assembly programming.
> I'd like to work on the ARM architecture.
> 
> Looking at the codes under the /sysdeps/arm directory, it seems there
> is only one assembly code for the string handling functions: strlen.S.
> I'd like to contribute to the project by committing assembly codes of
> the string handling functions for the ARM architecture.
> 
> If this job is available, it'll be my first contribution to an
> open-source project, and I'm really excited and looking forward to
> joining the glibc developer community.
> 
> Best regards,
> Nam-goo Lee
> 

Re: Contributing to the glibc Project

[Joseph Myers]

On Thu, 13 Oct 2016, Adhemerval Zanella wrote:

> For strlen we do have an armv6, armv6 thumb2, and the default one
> which should work on minimum supported arm (armv5?).

Minimum is v4 (though anything less than v4t may not work well with the 
EABI).

> Also note that for armv7+ we use ifunc to select of different
> implementation for memcpy. One possible work I would suggest you
> and use the memcpy* for amrv7 and create also a multiarch memmove
> implementation based on current armv7 strategies, since armv7 
> still uses the default memmove.S implementation.

Note that any string function patches motivated by performance need 
thorough before-and-after benchmarking to justify that they are 
improvements for the affected processors.  In addition to running the 
glibc testsuite of course - and for processors such as ARM that support 
both endiannesses, string tests need running for both endiannesses.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Contributing to the glibc Project

[Adhemerval Zanella]

On 13/10/2016 14:03, Joseph Myers wrote:
> On Thu, 13 Oct 2016, Adhemerval Zanella wrote:
> 
>> For strlen we do have an armv6, armv6 thumb2, and the default one
>> which should work on minimum supported arm (armv5?).
> 
> Minimum is v4 (though anything less than v4t may not work well with the 
> EABI).
> 
>> Also note that for armv7+ we use ifunc to select of different
>> implementation for memcpy. One possible work I would suggest you
>> and use the memcpy* for amrv7 and create also a multiarch memmove
>> implementation based on current armv7 strategies, since armv7 
>> still uses the default memmove.S implementation.
> 
> Note that any string function patches motivated by performance need 
> thorough before-and-after benchmarking to justify that they are 
> improvements for the affected processors.  In addition to running the 
> glibc testsuite of course - and for processors such as ARM that support 
> both endiannesses, string tests need running for both endiannesses.
> 

Indeed, all new performance algorithms should follow the usual
rationale.  I suggested memmove only because ARM default one
(sysdeps/arm/memmove.S) could use the similar strategies as already
placed on specialized one (__memcpy_{vfp,neon}) for backwards
copy.