From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id F37E03858D20; Wed, 17 Apr 2024 22:39:29 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org F37E03858D20 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1713393570; bh=uagOU6zBDPGbj+Lxvnn8Rzi35VyzvsVvYfBEEgdy2bE=; h=From:To:Subject:Date:In-Reply-To:References:From; b=g28YKnwhdFuRsAvfGw3H+aXmmXgOEpSQrou+pvTxIgfKkKe53iv1SoH1TL1ffAEsT v+VxzFYEdyfjVXKC89okWAATGDFE35Dpk/1GECtXFKgKNgHAk61HwFZJxIbsM963MZ ES0+RNCj1inmWZpj+f1IXpnLieoMq6qbbbR9tFVY= From: "segher at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/114759] Power: multiple issues with -mrop-protect Date: Wed, 17 Apr 2024 22:39:29 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: target X-Bugzilla-Version: 14.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: segher at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: bergner 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 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D114759 --- Comment #2 from Segher Boessenkool --- > 1. We always define the __ROP_PROTECT__ predefined macro when using -mrop= -protect, even when we've silently disabled ROP protection because of a too= old -mcpu=3DCPU value. We should only emit __ROP_PROTECT__ when it's lega= l to emit the ROP insns. No. Whenever the -mrop-protect option is in effect, we should do that predefine. If you want to refuse the option without a -mcpu=3D that can generate usefu= l code for it, that's fine, but that is not what we do. Instead, we generate code that will do the ROP-protection boogaloo on CPUs that implement support for that, and does nothing otherwise. > 2. We always disable shrink-wrapping when -mrop-protect is used, [...] Yes, this is problematic, and seems to be completely unnecessary. When usi= ng SWS at least -- but then we need to define a component for doing the ROP-protec= tion thing, of course. After all, it has to be done before anything else in the function. By exactly the same argument we should *also* do ROP-protection in all leaf functions, btw! > 3. We silently disable ROP protection for everything other than -mcpu=3D= power10. The binutils assembler accepts the ROP insns back to Power8, so w= e should emit them for Power8 and later. The ISA claims it will work for anything after ISA 2.04, even. > 4. We give an error when -mrop-protect is used with any -mabi=3DABI valu= e not equal to ELFv2, [...] Yes, we should make it work everywhere. Even on -m32. But it requires adjusting the ABI as well! 2) should be fixed, and 4) should be fixed by actually implementing it everywhere!=