On ppc64le gcc8 generates inlined code for str[n]cmp that valgrind memcheck
cannot proof correct. gcc9/trunk generates slightly different code for the
inlined strncmp code that valgrind memcheck can proof correct with some
patches. glibc uses inlined str[n]cmp in various functions.
Once the gcc patch has been backported (#1652929) glibc should be rebuild with
the new gcc to solve the valgrind bug (#1532205).
Created attachment 1510862 [details]
This is the patch I want to use to express the GCC build dependency.
However, in my testing, this is not sufficient to get a clean “valgrind /bin/true --help” run with the rebuilt glibc because bug 1532205 does not appear to be fixed in valgrind-3.14.0-4.el8 (although the bug is MODIFIED as of this writing).
(In reply to Florian Weimer from comment #4)
> Created attachment 1510862 [details]
> This is the patch I want to use to express the GCC build dependency.
> However, in my testing, this is not sufficient to get a clean “valgrind
> /bin/true --help” run with the rebuilt glibc because bug 1532205 does not
> appear to be fixed in valgrind-3.14.0-4.el8 (although the bug is MODIFIED as
> of this writing).
My apologies for this. I am somewhat confident that all the issues you are still seeing are on the valgrind side. But unfortunately they were only found now that we have a gcc with the new inlined strcmp patch and a glibc rebuild with it.
The basic issue is that valgrind sometimes splits loads in separate pieces because it wants to postprocess those pieces and put them back together in some different order. When it does that, it might report an invalid read for one of the pieces since it lost the information that this is one big (vector) load that might fall partially outside allocated memory. To fix that the load should be done in one piece with different IR doing the post processing. That way memcheck can correctly track the defined parts of the load.
There are currently 3 known instructions that need to be rewritten on the valgrind side:
- ldbrx, for which I have a pending patch upstream:
- lxvd2x (on power8)
- lxvb16x (on power9)
The last two seem to be somewhat special because they work differently on big-vs-little endian setups (we only care about little, but upstream cares about big too).
We also need to deal better with unaligned partial loads.
BTW. It would be convenient to have a new build in the compose so we can more easily test the issue on the valgrind side. It could be some time before we have a perfect valgrind package.
*** Bug 1657831 has been marked as a duplicate of this bug. ***
glibc-2.28-39.el8 explicitly requires the new GCC version. (Although glibc-2.28-38.el8 was already built with it.)
valgrind /bin/true --help outputs Invalid read for glibc-2.28-38.el8 and -39 with valgrind-3.14.0-4.el8 and -5 and valgrind /bin/true --help executes with no issues for both glibc-2.28-38.el8 and -39 with valgrind-3.14.0-6.el8 and higher.