This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: PowerPC: multiarch support for PPC32
- From: Adhemerval Zanella <azanella at linux dot vnet dot ibm dot com>
- To: libc-alpha at sourceware dot org
- Date: Tue, 04 Jun 2013 09:29:16 -0300
- Subject: Re: PowerPC: multiarch support for PPC32
- References: <51798805 dot 3010505 at linux dot vnet dot ibm dot com>
Just to keep track I pushed a new version of the patch set to azanella/multilib-ppc32.
It contains mostly cleanup and fixes.
On 04/25/2013 04:46 PM, Adhemerval Zanella wrote:
> Hi glibc community,
>
> I just pushed to azanella/multilib-ppc32 branch a multilib support for PowerPC32.
> Some considerations:
>
> * The support is complete with both string/etc. and fpu specialized functions.
>
> * Minimum architecture supported is current glibc one (basically powerpc, prior
> to POWER4).
>
> * With the patches I pushed some common implementation to sysdeps/powerpc/powerX
> from sysdeps/powerpc/power32/.. and this required some cleanup on PowerPC64
> side.
>
> * Each commit represent a symbol with first commit the initial support for the
> libc_ifunc mechanism, except the first one (initial support) and 20th one that
> setups the multiarch search order.
>
> * Some cleanup was done, although mostly focused on comments.
>
> * Current branch does not contain any ChangeLogs, but I intend to do so on patch
> posting.
>
> The patch set is quite extensive, 37 patches with large changes, so I would ask for
> recommendations is which will be the better way send the patch. Should I create
> sub-messages with proper ChangeLog for each patch or should I wait for some test
> with the branch?
>
> I do not intend to push for 2.18, although I'd like some early recommendation,
> advices, etc. so I could avoid pitfalls in the PowerPC64 implementation. Should I
> wait to 2.18 window close before start to post patches?
>
> I tested with GCC 4.4.6 and 4.7.3 on PowerPC32. I still running tests on different
> platforms and checking if an build issue related to gcc trunk is a compiler issue
> or a code one.
>
> Thanks for your attention.
>