Bug 1652932

Summary: glibc needs to be rebuild on ppc64le for new str[n]cmp inlined code
Product: Red Hat Enterprise Linux 8 Reporter: Mark Wielaard <mjw>
Component: glibcAssignee: Florian Weimer <fweimer>
Status: CLOSED CURRENTRELEASE QA Contact: Alexandra Petlanová Hájková <ahajkova>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 8.0CC: ahajkova, ashankar, codonell, dj, fsumsal, fweimer, mcermak, mnewsome, pfrankli
Target Milestone: rc   
Target Release: 8.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: glibc-2.28-39.el8 Doc Type: No Doc Update
Doc Text:
undefined
 Story Points: ---
Clone Of: Environment:
Last Closed: 2019-06-14 00:48:09 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 1652929    
Bug Blocks: 1532205    
Attachments:
Description Flags
0001-Rebuild-glibc-for-new-inline-string-functions-on-ppc.patch none

Description Mark Wielaard 2018-11-23 15:40:41 UTC 
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).
Comment 4 Florian Weimer 2018-12-03 11:22:29 UTC 
Created attachment 1510862 [details]
0001-Rebuild-glibc-for-new-inline-string-functions-on-ppc.patch

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).
Comment 6 Mark Wielaard 2018-12-03 13:20:39 UTC 
(In reply to Florian Weimer from comment #4)
> Created attachment 1510862 [details]
> 0001-Rebuild-glibc-for-new-inline-string-functions-on-ppc.patch
> 
> 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:
  https://bugs.kde.org/show_bug.cgi?id=386945#c44
- 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.
https://bugs.kde.org/show_bug.cgi?id=386945#c47

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.
Comment 8 Florian Weimer 2018-12-10 15:49:09 UTC 
*** Bug 1657831 has been marked as a duplicate of this bug. ***
Comment 9 Florian Weimer 2018-12-13 11:23:36 UTC 
glibc-2.28-39.el8 explicitly requires the new GCC version.  (Although glibc-2.28-38.el8 was already built with it.)
Comment 11 Alexandra Petlanová Hájková 2019-01-17 10:41:19 UTC 
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.

Beaker logs:
https://beaker.engineering.redhat.com/recipes/6393989#task86796674