On Thu, Aug 11, 2011 at 9:32 PM, Denys Vlasenko
wrote:
> IOW: I think the "optimized" memcpy code in your
> uclibc tree is buggy.
I think you are right. I will take up this issue with the vendor.
Thanks a lot for the help.
___
uClibc mailing list
uClibc
On Thu, Aug 11, 2011 at 6:53 AM, manish kumar wrote:
> On Thu, Aug 11, 2011 at 9:53 AM, Denys Vlasenko
> 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 exampl
On a MIPS 74K I would expect it to end up here:
>> 400338: 28c80008 slti t0,a2,8
>> 40033c: 1535 bnez t0,400414 <__BMIPS3300_memcpy_last8>
>> 400340: 00801021 move v0,a0
...
>> 00400414 <__BMIPS3300_memcpy_last8>:
>> 400414: 18c6
On Thu, Aug 11, 2011 at 9:53 AM, Denys Vlasenko
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 t
On Aug 9, 2011, at 10:25 PM, manish kumar wrote:
> On Wed, Aug 10, 2011 at 12:06 PM, Denys Vlasenko
> wrote:
>
>> Try disassembling a static binary.
>
> I disassembled the static version. It appears it is calling the CPU
> specific optimized memcpy() with unrolled loops. But then how can I
>
On Wed, Aug 10, 2011 at 12:06 PM, Denys Vlasenko
wrote:
> Try disassembling a static binary.
I disassembled the static version. It appears it is calling the CPU
specific optimized memcpy() with unrolled loops. But then how can I
fix this problem. I want this test case to crash.
The disassembly
On Wed, Aug 10, 2011 at 2:32 AM, manish kumar wrote:
> 00400570 :
> 400570: 3c0f0041 lui t7,0x41
> 400574: 8df90830 lw t9,2096(t7)
> 400578: 0328 jr t9
> 40057c: 25f80830 addiu t8,t7,2096
> 00400700 :
> 400700: 27b
On Wed, Aug 10, 2011 at 2:32 AM, manish kumar wrote:
> int main()
> {
> 400448: 55 push %rbp
> 400449: 48 89 e5 mov %rsp,%rbp
> size_t size = -1;
> 40044c: 48 c7 45 f8 ff ff ff movq
> $0x,0xfff8(%rb
On Tue, Aug 9, 2011 at 3:22 PM, manish kumar wrote:
> #include
> #include
>
> int main()
> {
> char *str1[10] = {src};
> char *str2[10] = {dest};
> memcpy(str1, str2, -1);
>
> return 1;
> }
>
> This simple test case of negative memcpy() fails on PC wi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/09/2011 06:22 AM, manish kumar wrote:
> #include #include
>
> int main() { char *str1[10] = {src}; char *str2[10] = {dest};
> memcpy(str1, str2, -1);
>
> return 1; }
>
> This simple test case of negative memcpy(
On Wed, Aug 10, 2011 at 1:54 AM, Rich Felker wrote:
> On Tue, Aug 09, 2011 at 06:49:58PM +0200, Laurent Bercot wrote:
>> I would guess that the glibc goes out of its way to check that the
>> memcpy() arguments are valid and makes a point to crash when they are
>> not, with is a safe behaviour but
On Tue, Aug 09, 2011 at 06:49:58PM +0200, Laurent Bercot wrote:
> I would guess that the glibc goes out of its way to check that the
> memcpy() arguments are valid and makes a point to crash when they are
> not, with is a safe behaviour but requires extra code, whereas the
> uClibc does not perfor
> #include
> #include
>
> int main()
> {
> char *str1[10] = {src};
> char *str2[10] = {dest};
> memcpy(str1, str2, -1);
>
> return 1;
> }
Depending on your gcc version and the compilation options you're using,
this program's behaviour might have nothing to do with the libc, because
mem
str2, -1);
>>
>> return 1;
>> }
>>
>> This simple test case of negative memcpy() fails on PC with glibc, but
>> executes well on uClibc on MIPS target. -1 should translate to a large
>> positive number and while doing memcpy(), program should access
>
On Tue, Aug 09, 2011 at 10:22:25PM +0900, manish kumar wrote:
> #include
> #include
>
> int main()
> {
>char *str1[10] = {src};
>char *str2[10] = {dest};
>memcpy(str1, str2, -1);
>
> return 1;
> }
>
> This simple test case of negati
#include
#include
int main()
{
char *str1[10] = {src};
char *str2[10] = {dest};
memcpy(str1, str2, -1);
return 1;
}
This simple test case of negative memcpy() fails on PC with glibc, but
executes well on uClibc on MIPS target. -1 should translate to a large
positive number and while
16 matches
Mail list logo
