https://bugs.kde.org/show_bug.cgi?id=386945
--- Comment #45 from Mark Wielaard <m...@klomp.org> ---
Unfortunately even with the ldbrx patch (which seems an OK improvement in
itself) we still have some issues.
ldbrx is also used on unaligned addresses. In which case even
--partial-loads-ok=yes doesn't help us.
For example this little program which has a string table with some strings at
odd addresses:
#include <stdlib.h>
#include <string.h>
#include <stdio.h>
int main (int argc, char **argv)
{
char *strtable = malloc (5);
// First element is the empty string.
strtable[0] = '\0';
// Second (and last) element is a short string.
strcpy (&strtable[1], "abc");
// What was the second string again?
int equal = strcmp (argv[0], &strtable[1]);
if (equal == 0)
puts ("yes");
else
puts ("no");
free (strtable);
return 0;
}
gcc -Wall -g -O2 -o table table.c
valgrind -q ./table
==7902== Invalid read of size 8
==7902== at 0x10000630: main (table.c:14)
==7902== Address 0x42e0041 is 1 bytes inside a block of size 5 alloc'd
==7902== at 0x408420C: malloc (vg_replace_malloc.c:299)
==7902== by 0x100005A7: main (table.c:7)
==7902==
no
Dump of assembler code for function main:
0x0000000010000580 <+0>: lis r2,4098
0x0000000010000584 <+4>: addi r2,r2,32512
0x0000000010000588 <+8>: mflr r0
0x000000001000058c <+12>: std r30,-16(r1)
0x0000000010000590 <+16>: std r31,-8(r1)
0x0000000010000594 <+20>: li r3,5
0x0000000010000598 <+24>: mr r30,r4
0x000000001000059c <+28>: std r0,16(r1)
0x00000000100005a0 <+32>: stdu r1,-48(r1)
0x00000000100005a4 <+36>: bl 0x10000560
<00000022.plt_call.malloc@@GLIBC_2.17>
0x00000000100005a8 <+40>: ld r2,24(r1)
0x00000000100005ac <+44>: lis r10,99
0x00000000100005b0 <+48>: li r8,0
0x00000000100005b4 <+52>: ori r10,r10,25185
0x00000000100005b8 <+56>: mr r31,r3
0x00000000100005bc <+60>: ld r3,0(r30)
0x00000000100005c0 <+64>: addi r4,r31,1
0x00000000100005c4 <+68>: stb r8,0(r31)
0x00000000100005c8 <+72>: stw r10,1(r31)
0x00000000100005cc <+76>: clrldi r9,r3,52
0x00000000100005d0 <+80>: cmpdi cr7,r9,4032
0x00000000100005d4 <+84>: bge cr7,0x100005e4 <main+100>
0x00000000100005d8 <+88>: clrldi r9,r4,52
0x00000000100005dc <+92>: cmpdi cr7,r9,4032
0x00000000100005e0 <+96>: blt cr7,0x1000062c <main+172>
0x00000000100005e4 <+100>: bl 0x10000520
<00000022.plt_call.strcmp@@GLIBC_2.17>
0x00000000100005e8 <+104>: ld r2,24(r1)
0x00000000100005ec <+108>: cmpwi cr7,r3,0
0x00000000100005f0 <+112>: bne cr7,0x1000074c <main+460>
0x00000000100005f4 <+116>: addis r3,r2,-2
0x00000000100005f8 <+120>: addi r3,r3,-29840
0x00000000100005fc <+124>: bl 0x10000540
<00000022.plt_call.puts@@GLIBC_2.17>
0x0000000010000600 <+128>: ld r2,24(r1)
0x0000000010000604 <+132>: mr r3,r31
0x0000000010000608 <+136>: bl 0x100004e0
<00000022.plt_call.free@@GLIBC_2.17>
0x000000001000060c <+140>: ld r2,24(r1)
0x0000000010000610 <+144>: addi r1,r1,48
0x0000000010000614 <+148>: li r3,0
0x0000000010000618 <+152>: ld r0,16(r1)
0x000000001000061c <+156>: ld r30,-16(r1)
0x0000000010000620 <+160>: ld r31,-8(r1)
0x0000000010000624 <+164>: mtlr r0
0x0000000010000628 <+168>: blr
0x000000001000062c <+172>: ldbrx r8,0,r3
=> 0x0000000010000630 <+176>: ldbrx r9,0,r4
0x0000000010000634 <+180>: li r10,0
0x0000000010000638 <+184>: cmpb r7,r8,r9
0x000000001000063c <+188>: cmpb r10,r8,r10
0x0000000010000640 <+192>: orc. r10,r10,r7
0x0000000010000644 <+196>: bne 0x10000734 <main+436>
0x0000000010000648 <+200>: addi r9,r3,8
0x000000001000064c <+204>: ldbrx r8,0,r9
0x0000000010000650 <+208>: addi r9,r4,8
0x0000000010000654 <+212>: ldbrx r9,0,r9
0x0000000010000658 <+216>: cmpb r10,r8,r10
0x000000001000065c <+220>: cmpb r7,r8,r9
0x0000000010000660 <+224>: orc. r10,r10,r7
0x0000000010000664 <+228>: bne 0x10000734 <main+436>
This means we have to handle unaligned partial reads somehow.
I am not sure we can. The code in memcheck/mc_main.c (mc_LOADVn_slow) dealing
with partial reads seems to very much rely on at least word alignment.
--
You are receiving this mail because:
You are watching all bug changes.
