RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1652932 - glibc needs to be rebuild on ppc64le for new str[n]cmp inlined code
Summary: glibc needs to be rebuild on ppc64le for new str[n]cmp inlined code
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: glibc
Version: 8.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: 8.0
Assignee: Florian Weimer
QA Contact: Alexandra Petlanová Hájková
URL:
Whiteboard:
: 1657831 (view as bug list)
Depends On: 1652929
Blocks: 1532205
TreeView+ depends on / blocked
 
Reported: 2018-11-23 15:40 UTC by Mark Wielaard
Modified: 2023-07-18 14:30 UTC (History)
9 users (show)

Fixed In Version: glibc-2.28-39.el8
Doc Type: No Doc Update
Doc Text:
undefined
Clone Of:
Environment:
Last Closed: 2019-06-14 00:48:09 UTC
Type: Bug
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
0001-Rebuild-glibc-for-new-inline-string-functions-on-ppc.patch (1.55 KB, patch)
2018-12-03 11:22 UTC, Florian Weimer
no flags Details | Diff

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


Note You need to log in before you can comment on or make changes to this bug.