Bug 1470115
| Summary: | gcc: Invalid IFUNC resolver in libgcc calls getauxval, leading to ppc64le relocation crash | ||
|---|---|---|---|
| Product: | Red Hat Developer Toolset | Reporter: | Florian Weimer <fweimer> |
| Component: | gcc | Assignee: | Marek Polacek <mpolacek> |
| Status: | CLOSED WONTFIX | QA Contact: | Martin Cermak <mcermak> |
| Severity: | high | Docs Contact: | |
| Priority: | urgent | ||
| Version: | DTS 7.0 RHEL 7 | CC: | abokovoy, agk, arjun, codonell, davejohansen, dj, extras-qa, fweimer, jakub, jwakely, kanderso, law, mcermak, mfabian, mnewsome, mpolacek, ohudlick, pfrankli, siddhesh |
| Target Milestone: | alpha | ||
| Target Release: | 7.0 | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | 1467526 | Environment: | |
| Last Closed: | 2018-04-30 16:46:05 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: | 1467526 | ||
| Bug Blocks: | |||
|
Description
Florian Weimer
2017-07-12 12:14:46 UTC
I think a fix in DTS7 is absolutely required. In order for us to stress test RHEL7 + DTS7 we build upstream glibc and report build status upstream using these tools. On top of that we need to be ready at a moments notice to use DTS7 internally on all of our architectures in the event we need a newer compiler to solve a customer issue. Is this patch all that needs to be done in GCC7? https://gcc.gnu.org/ml/gcc-patches/2017-07/msg00348.html (In reply to Marek Polacek from comment #2) > Is this patch all that needs to be done in GCC7? > https://gcc.gnu.org/ml/gcc-patches/2017-07/msg00348.html AFAIK, Yes, that's the patch. glibc 2.17 did not have the HWCAP fields in the TCB for __builtin_cpu_supports, though. That came in glibc 2.23 only. We could backport that, but then we run again into difficulties with RPM dependency management. (In reply to Florian Weimer from comment #4) > glibc 2.17 did not have the HWCAP fields in the TCB for > __builtin_cpu_supports, though. That came in glibc 2.23 only. We could > backport that, but then we run again into difficulties with RPM dependency > management. You are absolutely right. We would need to provide __parse_hwcap_and_convert_at_platform. The new symbol is used by gcc to ensure that when compiling you get a reference to the new feature symbol, and the application won't run if you move it to a system with an older libc. I spoke with Jakub about this and the conclusion is as follows: (a) Low priority Without proper glibc support for float128 users will not be interested in using DTS7 on ppc64le using float128. Therefore this has to be low priority. (b) Ported to stub libgcc.a DTS7 uses the system libgcc_s.so, but provides it's own libgcc.a, so that will have an impact in supporting this configuration. (c) Forces binaries to require a newer version of glibc. We can't require binaries use a newer version of glibc, because rpm doesn't understand how the new symbol creates a new dependency. However, users would get an error trying to start the application and we would have to document that this means you need a new glibc. We could force DTS7 gcc to require that new glibc on ppc64le in order to get this working on developer workstations, but it goes against the idea of DTS7. You could argue that this is "the first release for ppc64le" and so can require the latest glibc, but that's a fragile requirement. In summary: ========== Given (a), (b) and (c), we probably have to not enable support for hardware float128 for POWER9 from DTS7 (or RHEL7 at all). This support will come naturally in later RHEL as the core components are updated. Thoughts? (In reply to Carlos O'Donell from comment #5) > In summary: > ========== > Given (a), (b) and (c), we probably have to not enable support for hardware > float128 for POWER9 from DTS7 (or RHEL7 at all). This support will come > naturally in later RHEL as the core components are updated. > > Thoughts? Some alternatives exist: (1) Don't use IFUNC in gcc. Change all of the DTS7 HW/SW redirects for float128 to do the redirection at runtime and verify that none of those calls are earlier than when getauxval() data is setup. (2) Use a new POWER9 multilib. Create a POWER9 multilib for gcc which assumes HW float128, and is selected by ld.so based on AT_PLATFORM, and then have the POWER8 multilib assume SW float128. This seems like a lot of work at this point for a partial feature we can't fully support in glibc. (In reply to Carlos O'Donell from comment #5) > Given (a), (b) and (c), we probably have to not enable support for hardware > float128 for POWER9 from DTS7 (or RHEL7 at all). This support will come > naturally in later RHEL as the core components are updated. Do you propose to hardwire __builtin_cpu_supports ("ieee128") to 0 in the compiler, without calling getauxval or considering the HWCAP bits? I expect that this would work for glibc. (In reply to Florian Weimer from comment #7) > (In reply to Carlos O'Donell from comment #5) > > Given (a), (b) and (c), we probably have to not enable support for hardware > > float128 for POWER9 from DTS7 (or RHEL7 at all). This support will come > > naturally in later RHEL as the core components are updated. > > Do you propose to hardwire __builtin_cpu_supports ("ieee128") to 0 in the > compiler, without calling getauxval or considering the HWCAP bits? I expect > that this would work for glibc. Yes, but you need (2), a new multilib for POWER9, which allows you to make that assumption. (In reply to Carlos O'Donell from comment #8) > (In reply to Florian Weimer from comment #7) > > (In reply to Carlos O'Donell from comment #5) > > > Given (a), (b) and (c), we probably have to not enable support for hardware > > > float128 for POWER9 from DTS7 (or RHEL7 at all). This support will come > > > naturally in later RHEL as the core components are updated. > > > > Do you propose to hardwire __builtin_cpu_supports ("ieee128") to 0 in the > > compiler, without calling getauxval or considering the HWCAP bits? I expect > > that this would work for glibc. > > Yes, but you need (2), a new multilib for POWER9, which allows you to make > that assumption. Oh, I see, yes, you could always set it to 0 and get softfp support, but the point of POWER9 is get the hardware support :-) (In reply to Carlos O'Donell from comment #9) > (In reply to Carlos O'Donell from comment #8) > > (In reply to Florian Weimer from comment #7) > > > (In reply to Carlos O'Donell from comment #5) > > > > Given (a), (b) and (c), we probably have to not enable support for hardware > > > > float128 for POWER9 from DTS7 (or RHEL7 at all). This support will come > > > > naturally in later RHEL as the core components are updated. > > > > > > Do you propose to hardwire __builtin_cpu_supports ("ieee128") to 0 in the > > > compiler, without calling getauxval or considering the HWCAP bits? I expect > > > that this would work for glibc. > > > > Yes, but you need (2), a new multilib for POWER9, which allows you to make > > that assumption. > > Oh, I see, yes, you could always set it to 0 and get softfp support, but the > point of POWER9 is get the hardware support :-) OK, by default this will happen: (a) configure.ac will detect glibc < 2.23 (b) rs6000.c will configure out the builtins that are used by the IFUNC and have them return 0. (c) Because of (b) all the ifuncs will default to SW support. So there isn't anything we need to do. I think this ticket can be CLOSED/WONTFIX, we'll just have softp float128 support in ppc64le, even on POWER9 hardware which could in theory support it. If the request ever materializes it would be for a fully supported implementation of float128 with glibc functions that accompany it and then we'd have to recommend something else. Closing as per Comment 10. |