[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 01 Aug 2013 10:03:29 +0200
From: Luca Barbato <lu_zero@...too.org>
To: musl@...ts.openwall.com
Subject: Re: Solving the recursive memcpy/memset/etc. issue
On 01/08/13 08:20, Rich Felker wrote:
> On Thu, Aug 01, 2013 at 08:05:01AM +0200, Luca Barbato wrote:
>>> The only fully viable option I see is replacing the code for
>>> these functions with code that uses volatile objects so as to
>>> make optimization utterly impossible. This will of course make
>>> them incredibly slow, but at least we would have safe, working C
>>> code, and we could add asm for each supported arch.
>>
>> Not exactly great.
>
> Well, we really need to add the arch asm anyway, as ugly as it is.
> Right now most archs have memcpy running 2-5x slower than it should.
> I could _try_ writing C to handle the unaligned (hard) cases well,
> basically mimicing what the proposed asm for arm does, but I don't
> think it will be competitive, just "not as slow". And we'd still
> have to worry about it getting miscompiled...
I trust you on that.
>>> An alternative might be to test the compiler in configure to
>>> determine if, with the selected CFLAGS, it generates recursive
>>> code for these functions, and if so, defining a macro that causes
>>> musl to revert to the volatile code.
>>
>> Sounds much better.
>
> Well, it would be an ugly heuristic like running cc -S -o - on
> src/string/memcpy.c, with -Dmemcpy=noname or something, and grepping
> the output for memcpy...
Indeed.
>>> Other ideas? For now, if -fno-tree-loop-distribute-patterns fixes
>>> it (still waiting on confirmation for this) I'm going to commit
>>> that to configure, but it doesn't seem like a viable long-term
>>> solution.
>>
>> I'd rather check and error out reporting the compiler is broken.
>> Then have an explicit configure option to try to workaround it.
>
> If it were just a temporary regression, I would agree, but I think
> the GCC position is that this is not a bug...
Given that even glibc breaks on that...
> I figured someone would say that, and almost put a preemptive note
> in my post. clang/LLVM was the first to have this sort of bug of
> ignoring -ffreestanding, only much worse, making invalid assumptions
> about the result value of malloc inside the malloc implementation...
Understandable, clang is a "young" project. It is like expecting cparser
to be able to compile Libav.
> Competition is unfortunately the source of our woes, not the
> solution. GCC and clang/LLVM are facing competition to be the best at
> compiling application code, and since compiling the implementation
> itself is an unusual, unexciting usage case, nobody's really watching
> out for how they break that one in the race to have the fastest
> application code...
Implementors and distributors might have to say a thing or two about
that. If they manage to break singlehandedly musl, uclibc, glibc and
bionic and refuse to acknowledge the bug then I guess some people might
question their direction.
lu
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.
