|
From: Patrick J. L. <lop...@gm...> - 2017-04-25 23:21:25
|
On Tue, Apr 25, 2017 at 12:22 PM, Carl E. Love <ce...@us...> wrote:
>
> I did try recompiling the test case with -fno-builtin-strcmp and running without any
> additional Valgrind flags and still got the issue.
Hm. You are sure the warning is still from the application code and
not the C library?
That is... strange. I thought the whole point of -fno-builtin-XXX was
to force the compiler to invoke the C library, forgetting whatever it
thinks it knows about the function. Is it possible strcmp() is
actually "inline" in your glibc headers?
Another idea: I suspect it would be pretty simple to hack the
partial-loads-ok logic to mark the "extra" bytes as defined rather
than undefined. Search memcheck/mc_main.c for "partial-loads-ok"; the
change should be just a line or two in mc_LOADV_128_or_256_slow().
...
Specifically, you can try commenting out this "for" loop on lines
1354-1355 of mc_main.c:
for (j = szL-1; j >= 0; j--)
res[j] |= pessim[j];
(Note: It has been a long time since I was in this code, so I could be
completely wrong. If so, hopefully Julian will correct me...)
Of course, this does risk masking real errors. But it should be a
quick way to move forward while exploring other options. And this sort
of partially-valid aligned load is probably not terribly common apart
from this sort of optimization.
That said, -fno-builtin-strcmp really should have caused GCC to emit a
call to the C library strcmp(). I suggest investigating why it didn't.
- Pat
|