Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 10 Jul 2013 14:38:36 -0500
From: Rob Landley <>
Subject: Re: Thinking about release

On 07/09/2013 12:37:12 AM, Rich Felker wrote:
> On Tue, Jul 09, 2013 at 05:06:21PM +1200, Andre Renaud wrote:
> > The git tree is available here:
> >  
> It's an open question whether it's better to sync something like this
> with an 'upstream' or adapt it to musl coding conventions. Generally
> musl uses explicit instructions rather than pseudo-instructions/macros
> for prologue and epilogue, and does not use named labels.

Do your own local version. You can always copy ideas from other  
projects if "upstream" changes later.

> > Does anyone have any comments on the suitability of this code, or  
> what
> If nothing else, it fails to be armv4 compatible.

Query: did you ever implement a non-thumb version of armv4 eabi  
support? I remember some discussion about it being possible, I don't  
remember the outcome.

> Fixing that should
> not be hard, but it would require a bit of an audit. The return
> sequences are the obvious issue, but there may be other instructions
> in use that are not available on armv4 or maybe not even on armv5...?

I've beaten armv4-only, armv4t-only, and armv5-only modes out of qemu.  
That's the reason for the first half of my versatile patch:

> > kind of more rigorous testing could be applied?
> See above.
> What also might be worth testing is whether GCC can compete if you
> just give it a naive loop (not the fancy pseudo-vectorized stuff
> currently in musl) and good CFLAGS. I know on x86 I was able to beat
> the fanciest asm strlen I could come up with simply by writing the
> naive loop in C and unrolling it a lot.

Duff's device!


Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.