https://bugs.kde.org/show_bug.cgi?id=386945
--- Comment #15 from Julian Seward <jsew...@acm.org> ---
I have a patch which I've been using for investigating this. It reduces the
noise level significantly, but doesn't remove it entirely. I'll post it in
a following comment. In the meantime I have a small failing testcase and a
question about acsawdey's strcmp implementation. Here's the testcase:
__attribute__((noinline))
char* setup() { return strndup("abcdef", 12); }
int main (void) {
char* x = setup();
return strcmp(x, "abcdef") == 0 ? 99 : 77;
}
|setup| is done out of line only so as to make the assembly for |main|
easier to follow.
Even with the abovementioned patch in place, Memcheck still reports a branch
on undefined values in |main|, in the inlined |strcmp|. This is when
compiled with gcc-7.3.0 at -O2.
I single-stepped through this with GDB attached to Valgrind, so I can look
at both the register values and what Memcheck thinks their definedness state
is, after every instruction. The important part of the trace follows. A
"." means the instruction was executed. ".nt" is "not taken" and ".t" is
"taken".
0000000010000450 <main>:
. 10000450: 03 10 40 3c lis r2,4099
. 10000454: 00 81 42 38 addi r2,r2,-32512
. 10000458: a6 02 08 7c mflr r0
. 1000045c: 10 00 01 f8 std r0,16(r1)
. 10000460: a1 ff 21 f8 stdu r1,-96(r1)
. 10000464: 25 03 00 48 bl 10000788 <setup+0x8>
. 10000468: fe ff 82 3c addis r4,r2,-2
. 1000046c: 78 88 84 38 addi r4,r4,-30600
. 10000470: 20 05 69 78 clrldi r9,r3,52
. 10000474: c0 0f a9 2f cmpdi cr7,r9,4032
.nt 10000478: 5c 01 9c 40 bge cr7,100005d4 <main+0x184>
. 1000047c: fe ff 42 3d addis r10,r2,-2
. 10000480: 28 1c 20 7d ldbrx r9,0,r3
. 10000484: 78 1b 68 7c mr r8,r3
. 10000488: 78 88 4a 39 addi r10,r10,-30600
. 1000048c: 28 54 40 7d ldbrx r10,0,r10
At this point, we've loaded r10 from presumably a constant pool, and it
contains "abcdef\0\0", all bytes defined. Also, we've loaded r9 from the
block allocated by strndup. It just so happens that r9 also now holds the
value "abcdef\0\0", but because that block is only 7 bytes long (as we
expect), that last \0 is marked as undefined.
. 10000490: 51 48 6a 7c subf. r3,r10,r9
Now r3 contains zero, because r10 == r9, but the lowest 8 bits of r3 are
marked as undefined, because the lowest 8 bits of r9 are undefined.
.t 10000494: 2c 00 82 41 beq 100004c0 <main+0x70> *********
At this beq, Memcheck issues as error. It believes -- correctly, I think --
that the branch depends on uninitialised data. Specifically, we are
comparing "abcdef\0\0" with "abcdef\0<undefined>", and since the 7 defined
bytes are identical, the branch actually depends on the undefined lowest
byte of r9.
10000498: 00 00 e0 38 li r7,0
1000049c: f8 53 28 7d cmpb r8,r9,r10
100004a0: f8 3b 27 7d cmpb r7,r9,r7
100004a4: 38 43 e8 7c orc r8,r7,r8
100004a8: 74 00 08 7d cntlzd r8,r8
100004ac: 08 00 08 39 addi r8,r8,8
100004b0: 30 46 23 79 rldcl r3,r9,r8,56
100004b4: 30 46 4a 79 rldcl r10,r10,r8,56
100004b8: 50 18 6a 7c subf r3,r10,r3
100004bc: 20 01 00 48 b 100005dc <main+0x18c>
. 100004c0: f8 1b 29 7d cmpb r9,r9,r3
. 100004c4: 00 00 a9 2f cmpdi cr7,r9,0
.t 100004c8: 14 01 9e 40 bne cr7,100005dc <main+0x18c>
So two questions:
(1) Does the above analysis seem correct?
(2) If so, am I correct to understand that the branch on uninitialised data
is intended, and that this is "fixed up" later on (perhaps beginning at
100004c0) so that the correct answer is nevertheless obtained?
--
You are receiving this mail because:
You are watching all bug changes.
