From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id A9D563858D3C; Tue, 28 Feb 2023 08:05:42 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org A9D563858D3C DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1677571542; bh=6iB+RZThPmGp9A16EoQ6TqQxeZhUfuUCd01sMSHQtpc=; h=From:To:Subject:Date:In-Reply-To:References:From; b=PDrOlBC3XdWzttlnpQdFA2wN4XOi35/23ZmgOGoeFjcEOrVXIVXUlWDdndPHe+kyO cyIX9C7jUqJRg/rjcas28nwjGTtggYY8olVGnUotu9u6wQw2d++u8bMTydbTJe2VkJ TroZOvaHmG+Mdq3pJS6v6n9u+uYgu5ywtjdh99y0= From: "amodra at gmail dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/108315] -mcpu=power10 changes ABI Date: Tue, 28 Feb 2023 08:05:42 +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: 13.0 X-Bugzilla-Keywords: ABI, wrong-code X-Bugzilla-Severity: normal X-Bugzilla-Who: amodra at gmail dot com X-Bugzilla-Status: UNCONFIRMED 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: cc 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=3D108315 Alan Modra changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |amodra at gmail dot com --- Comment #5 from Alan Modra --- Any caller of bar should be fine. The localentry value of 1 means it is advertised as having no requirement on r2 or r12 and r2 is *not* preserved.= A call that uses R_PPC64_REL24 to bar ought to have an r2 saving stub inserte= d by the linker and the nop after the call changed to restore r2. GNU ld will do exactly that. 0000000010000540 <00000047.long_branch.bar>: 10000540: 18 00 41 f8 std r2,24(r1) 10000544: 4c 02 00 48 b 10000790 ... 00000000100005a0
: 100005a0: 02 10 40 3c lis r2,4098 100005a4: 00 7f 42 38 addi r2,r2,32512 100005a8: a6 02 08 7c mflr r0 100005ac: 00 00 00 60 nop 100005b0: 20 80 62 e8 ld r3,-32736(r2) 100005b4: 10 00 01 f8 std r0,16(r1) 100005b8: e1 ff 21 f8 stdu r1,-32(r1) 100005bc: 85 ff ff 4b bl 10000540 <00000047.long_branch.bar> 100005c0: 18 00 41 e8 ld r2,24(r1) There isn't a problem if bar is passed the address of a non-pcrel function = in a shared library as it is in your example. The call in bar will go to the gl= obal entry point of foo, which will set up r2. The same thing happens when link= ing against foo.o, the function pointer address is that of the global entry of = foo. [amodra@gcc135 p10-interop]$ ./smain=20 Hello from foo Hello, World! (My dynamic main won't run on gcc135 due to my build machine having a more recent glibc, but I'm confident it would run if I fixed that.) I don't see any problem here other than (presumably) missing linker support= .=