On Thu, Aug 11, 2011 at 6:53 AM, manish kumar <[email protected]> wrote: > On Thu, Aug 11, 2011 at 9:53 AM, Denys Vlasenko > <[email protected]> wrote: >> ...but the below doesn't look like memcpy from uclibc: >> in iclibc tree, uClibc/libc/string/mips/memcpy.S is hardly >> 5 screenfuls of code including comments, >> and it, for example, doesn't use "pref" instruction >> (and never did according to git log). >> >> Whereas code below is HUGEST: nearly FORTY screenfuls, >> and it uses "pref" insn. >> >> Google code search failed to find the source >> (I looked for "memcpy detect_done"). >> >> Is this a modified uclibc, with someone's >> "more optimized" memcpy? > > My uClibc/libc/string/mips/memcpy.S is different from the uClibc > tree. I guess it is optimized one for the target. Anyway, how can it > copy such a huge data?
I suspect it doesnt copy anything at all, because memcpy exit condition is likely "cnt <= 0". (I don't know MIPS assembly enough to check it). In "sanely" sized memcpy's, cnt, when interpreted as signed int32, is > 0, but in your case it is < 0 already. > Or is it not copying anything when ssize_t = -1? I think yes. IOW: I think the "optimized" memcpy code in your uclibc tree is buggy. -- vda _______________________________________________ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
