From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id D4D193864826; Tue, 3 Aug 2021 16:42:46 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org D4D193864826 From: "stefan.kneifel at bluewin dot ch" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/101726] target_clone resolver does not generate PIC despite -fPIC Date: Tue, 03 Aug 2021 16:42:45 +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: 11.2.1 X-Bugzilla-Keywords: wrong-code X-Bugzilla-Severity: normal X-Bugzilla-Who: stefan.kneifel at bluewin dot ch X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: marxin 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: Tue, 03 Aug 2021 16:42:46 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D101726 --- Comment #2 from Stefan Kneifel --- OK, so declaring the default function as local might make gcc assume that t= he function body is available in the same translation unit, thus rendering the relocation locally resolvable.=20 Thus said, I tried to apply the following patch: --------------------------------------------------------- diff -ruN a/gcc/multiple_target.c b/gcc/multiple_target.c --- a/gcc/multiple_target.c 2021-07-28 11:09:49.000000000 +0200 +++ b/gcc/multiple_target.c 2021-08-03 14:45:00.341857265 +0200 @@ -172,7 +172,6 @@ /* FIXME: copy of cgraph_node::make_local that should be cleaned up in next stage1. */ - node->make_decl_local (); node->set_section (NULL); node->set_comdat_group (NULL); node->externally_visible =3D false; --------------------------------------------------------- and it seems to fix the problem (disassembler output of test case): --------------------------------------------------------- test.o: file format elf64-x86-64 Disassembly of section .text: 0000000000000000 <_Z3barv>: 0: e9 00 00 00 00 jmpq 5 <_Z3barv+0x5> 1: R_X86_64_PLT32 _Z3foov-0x4 Disassembly of section .text._Z3foov.resolver: 0000000000000000 <_Z3foov.resolver>: 0: 51 push %rcx 1: e8 00 00 00 00 callq 6 <_Z3foov.resolver+0x6> 2: R_X86_64_PLT32 __cpu_indicator_init-0x4 6: 48 8b 05 00 00 00 00 mov 0x0(%rip),%rax # d <_Z3foov.resolver+0xd> 9: R_X86_64_REX_GOTPCRELX __cpu_model-0x4 d: 8b 40 0c mov 0xc(%rax),%eax 10: 0f ba e0 0f bt $0xf,%eax 14: 73 09 jae 1f <_Z3foov.resolver+0x1f> 16: 48 8b 05 00 00 00 00 mov 0x0(%rip),%rax # 1d <_Z3foov.resolver+0x1d> 19: R_X86_64_REX_GOTPCRELX _Z3foov.avx512f.0-0= x4 1d: eb 25 jmp 44 <_Z3foov.resolver+0x44> 1f: 0f ba e0 0a bt $0xa,%eax 23: 73 09 jae 2e <_Z3foov.resolver+0x2e> 25: 48 8b 05 00 00 00 00 mov 0x0(%rip),%rax # 2c <_Z3foov.resolver+0x2c> 28: R_X86_64_REX_GOTPCRELX _Z3foov.avx2.1-0x4 2c: eb 16 jmp 44 <_Z3foov.resolver+0x44> 2e: 0f ba e0 09 bt $0x9,%eax 32: 73 09 jae 3d <_Z3foov.resolver+0x3d> 34: 48 8b 05 00 00 00 00 mov 0x0(%rip),%rax # 3b <_Z3foov.resolver+0x3b> 37: R_X86_64_REX_GOTPCRELX _Z3foov.avx.2-0x4 3b: eb 07 jmp 44 <_Z3foov.resolver+0x44> 3d: 48 8b 05 00 00 00 00 mov 0x0(%rip),%rax # 44 <_Z3foov.resolver+0x44> 40: R_X86_64_REX_GOTPCRELX _Z3foov.default.3-0= x4 44: 5a pop %rdx 45: c3 retq=20=20=20 --------------------------------------------------------- However, as a total GCC greenhorn I'm absolutely not sure of any side effec= ts that could be introduced by this hack ;-) so please Martin check that thoroughly, if it shouldn't be fixed in a more sophisticated way. It might revert the "Bug 81238" patch. Thank you very much!=