Re: Help on memchr() EGLIBC assembly code
On Mon, Jul 13, 2009 at 6:17 PM, Aurelien Jarno<aurelien@aurel32.net> wrote:
> On Mon, Jul 13, 2009 at 02:24:00PM -0400, Carlos O'Donell wrote:
>> On Mon, Jul 13, 2009 at 1:31 PM, Aurelien Jarno<aurelien@aurel32.net> wrote:
>> > With a lot of patches (E)GLIBC 2.10 builds on alpha, but it fails on the
>> > testsuite for the memchr() function, which is an optimized assembly code
>> > on alpha. Unfortunately I don't speak alpha assembly very well, so help
>> > is needed.
>> >
>> > The problem is that the memchr() function on alpha uses prefetch, which
>> > can cause a page boundary to be crossed, while the standards (POSIX and
>> > C99) says it should stop when a match is found.
>> >
>> > I have built a small testcase (see file attached), which contains the
>> > code to trigger the bug and the assembly code of the memchr() function,
>> > copied from EGLIBC.
>> >
>> > It would be nice if someone can fix the assembly code so that the
>> > prefetching does not create memory faults. Thanks in advance.
>>
>> If you remove:
>> ./sysdeps/alpha/alphaev6/memchr.S
>> ./sysdeps/alpha/memchr.S
>> and allow the build to fallback on string/memchr.c do the tests pass?
>>
>> You can always add memchr.S routines back in a later release if you
>> need an immediate workaround.
>
> Yeah, it works, and that's actually my plan if I get no answer. But I
> would really like to see this fixed now, as otherwise, it will most
> probably stay like that indefinitely.
>
> --
> Aurelien Jarno GPG: 1024D/F1BCDB73
> aurelien@aurel32.net http://www.aurel32.net
>
I'm copying Richard Henderson and Ivan Kokshayshy on this, as they are
without a doubt the most knowledgeable people about this sort of
thing.
As an aside, please make sure these two bugs are fixed in eglibc (I
don't know if they exist in eglibc, but I do realize that you filed
them against glibc yourself -- so this is just a reminder).
http://sources.redhat.com/bugzilla/show_bug.cgi?id=5350
http://sources.redhat.com/bugzilla/show_bug.cgi?id=5400
Matt
Reply to: