From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 90E72397141C; Wed, 10 Feb 2021 14:09:54 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 90E72397141C From: "mark at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug rtl-optimization/98692] Unitialized Values reported only with -Os Date: Wed, 10 Feb 2021 14:09:54 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: rtl-optimization X-Bugzilla-Version: 10.2.1 X-Bugzilla-Keywords: diagnostic X-Bugzilla-Severity: normal X-Bugzilla-Who: mark at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2021 14:09:54 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D98692 --- Comment #18 from Mark Wielaard --- The current thinking (Julian did the thinking, I am just repeating) is that this is caused by the way the _savegpr and/or restgpr functions return using blr. PPC has two special "lets zap the red zone" (the 288 bytes below the stack pointer) cases: # define VG_STACK_REDZONE_SZB 288 // number of addressable bytes below= R1 // from 64-bit PowerPC ELF ABI=20 // Supplement 1.7 guest_ppc_zap_RZ_at_blr guest is ppc64-linux =3D=3D> True guest is ppc32-linux =3D=3D> False guest is other =3D=3D> inapplicable guest_ppc_zap_RZ_at_bl guest is ppc64-linux =3D=3D> const True guest is ppc32-linux =3D=3D> const False guest is other =3D=3D> inapplicable guest_stack_redzone_size guest is ppc32-linux =3D=3D> 0 guest is ppc64-linux =3D=3D> 288 guest is amd64-linux =3D=3D> 128 guest is other =3D=3D> inapplicable /* PPC and AMD64 GUESTS only: how many bytes below the=20 stack pointer are validly addressible? */ Int guest_stack_redzone_size; /* PPC GUESTS only: should we zap the stack red zone at a 'blr' (function return) ? */ Bool guest_ppc_zap_RZ_at_blr; /* PPC GUESTS only: should we zap the stack red zone at a 'bl' (function call) ? Is supplied with the guest address of the target of the call since that may be significant. If NULL, is assumed equivalent to a fn which always returns False. */ Bool (*guest_ppc_zap_RZ_at_bl)(Addr); # if defined(VGP_ppc32_linux) vex_abiinfo.guest_ppc_zap_RZ_at_blr =3D False; vex_abiinfo.guest_ppc_zap_RZ_at_bl =3D NULL; # endif # if defined(VGP_ppc64be_linux) vex_abiinfo.guest_ppc_zap_RZ_at_blr =3D True; vex_abiinfo.guest_ppc_zap_RZ_at_bl =3D const_True; vex_abiinfo.host_ppc_calls_use_fndescrs =3D True; # endif # if defined(VGP_ppc64le_linux) vex_abiinfo.guest_ppc_zap_RZ_at_blr =3D True; vex_abiinfo.guest_ppc_zap_RZ_at_bl =3D const_True; vex_abiinfo.host_ppc_calls_use_fndescrs =3D False; # endif What happens on a blr function return is that, based on the guest_ppc_zap_RZ_at_blr value, the redzone is marked as containing undefined values. And indeed, with this patch: diff --git a/coregrind/m_translate.c b/coregrind/m_translate.c index 332202a91..6dd01afac 100644 --- a/coregrind/m_translate.c +++ b/coregrind/m_translate.c @@ -1709,7 +1709,7 @@ Bool VG_(translate) ( ThreadId tid, # endif # if defined(VGP_ppc64le_linux) - vex_abiinfo.guest_ppc_zap_RZ_at_blr =3D True; + vex_abiinfo.guest_ppc_zap_RZ_at_blr =3D False; vex_abiinfo.guest_ppc_zap_RZ_at_bl =3D const_True; vex_abiinfo.host_ppc_calls_use_fndescrs =3D False; # endif The warning goes away. But is that the right thing to do always? It seems to mask issues where a function is using the red zone values set by another function.=