https://bugs.kde.org/show_bug.cgi?id=430354
Bug ID: 430354
Summary: ppc stxsibx and stxsihx instructions write too much
data
Product: valgrind
Version: unspecified
Platform: Other
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: memcheck
Assignee: jsew...@acm.org
Reporter: m...@klomp.org
CC: c...@us.ibm.com, will_schm...@vnet.ibm.com
Target Milestone: ---
On a system with a power9 optimized glibc memcheck/tests/str_tester (and any
other application using some of the glibc string functions) fail with:
==473431== Invalid write of size 8
==473431== at 0x419C4CC: strndup (strndup.c:48)
==473431== by 0x1000B08F: test_strndup (str_tester.c:1297)
==473431== by 0x1000C043: main (str_tester.c:1528)
==473431== Address 0x4300046 is 6 bytes inside a block of size 7 alloc'd
==473431== at 0x40A428C: malloc (vg_replace_malloc.c:307)
==473431== by 0x419C4B3: strndup (strndup.c:43)
==473431== by 0x1000B08F: test_strndup (str_tester.c:1297)
==473431== by 0x1000C043: main (str_tester.c:1528)
Looking with gdb finds:
0x000000000419c4cc in __GI___strndup (s=0x1000c418 "abcdef", n=<optimized out>)
at strndup.c:48
48 new[len] = '\0';
Dump of assembler code for function __GI___strndup:
0x000000000419c480 <+0>: addis r2,r12,22
0x000000000419c484 <+4>: addi r2,r2,-20864
0x000000000419c488 <+8>: mflr r0
0x000000000419c48c <+12>: std r30,-16(r1)
0x000000000419c490 <+16>: std r31,-8(r1)
0x000000000419c494 <+20>: std r0,16(r1)
0x000000000419c498 <+24>: stdu r1,-48(r1)
0x000000000419c49c <+28>: mr r30,r3
0x000000000419c4a0 <+32>: bl 0x41ae390 <__strnlen_ppc>
0x000000000419c4a4 <+36>: nop
0x000000000419c4a8 <+40>: mr r31,r3
0x000000000419c4ac <+44>: addi r3,r3,1
0x000000000419c4b0 <+48>: bl 0x4118cc0 <00000025.plt_call.malloc>
0x000000000419c4b4 <+52>: ld r2,24(r1)
0x000000000419c4b8 <+56>: mr. r9,r3
0x000000000419c4bc <+60>: beq 0x419c4dc <__GI___strndup+92>
0x000000000419c4c0 <+64>: xxspltib vs0,0
0x000000000419c4c4 <+68>: mr r4,r30
0x000000000419c4c8 <+72>: mr r5,r31
=> 0x000000000419c4cc <+76>: stxsibx vs0,r9,r31
0x000000000419c4d0 <+80>: bl 0x4118c80
<00000025.plt_call.__GI_memcpy>
0x000000000419c4d4 <+84>: ld r2,24(r1)
0x000000000419c4d8 <+88>: mr r9,r3
0x000000000419c4dc <+92>: addi r1,r1,48
0x000000000419c4e0 <+96>: mr r3,r9
0x000000000419c4e4 <+100>: ld r0,16(r1)
0x000000000419c4e8 <+104>: ld r30,-16(r1)
0x000000000419c4ec <+108>: ld r31,-8(r1)
0x000000000419c4f0 <+112>: mtlr r0
0x000000000419c4f4 <+116>: blr
0x000000000419c4f8 <+120>: .long 0x0
0x000000000419c4fc <+124>: .long 0x1000000
0x000000000419c500 <+128>: .long 0x280
End of assembler dump.
So it is using stxsibx to write one byte at the end of the string.
But stxsibx is implemented by first reading a whole word, merging in the new
byte, and then writing out the whole word. Causing memcheck to warn the wrote
is beyond the end of (malloced) string buffer.
The the stxsihx (Store VSX Scalar as Integer Halfword Indexed X-form)
instruction does something similar.
It isn't immediately clear why the code isn't just storing the byte directly,
IRStmt_Store seems fine to store byte or half word sized data, and so seems the
ppc backend.
--
You are receiving this mail because:
You are watching all bug changes.
