From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 1944) id 31EDA3857340; Wed, 20 Dec 2023 16:00:10 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 31EDA3857340 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable From: Szabolcs Nagy To: bfd-cvs@sourceware.org Subject: [binutils-gdb/binutils-2_41-branch] bfd: aarch64: Avoid BTI stub for a PLT that has BTI X-Act-Checkin: binutils-gdb X-Git-Author: Szabolcs Nagy X-Git-Refname: refs/heads/binutils-2_41-branch X-Git-Oldrev: 95a26c1f3de31f82162dda78e571cf0e58d11833 X-Git-Newrev: 0c0527d30bcb168691faa7a611a54cf68d1d1770 Message-Id: <20231220160010.31EDA3857340@sourceware.org> Date: Wed, 20 Dec 2023 16:00:10 +0000 (GMT) X-BeenThere: binutils-cvs@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Binutils-cvs mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Dec 2023 16:00:10 -0000 https://sourceware.org/git/gitweb.cgi?p=3Dbinutils-gdb.git;h=3D0c0527d30bcb= 168691faa7a611a54cf68d1d1770 commit 0c0527d30bcb168691faa7a611a54cf68d1d1770 Author: Szabolcs Nagy Date: Wed Oct 18 16:12:56 2023 +0100 bfd: aarch64: Avoid BTI stub for a PLT that has BTI =20 We decide to emit BTI stubs based on the instruction at the target location. But PLT code is generated later than the stubs so we always read 0 which is not a valid BTI. =20 Fix the logic to special case the PLT section: this is code the linker generates so we know when it will have BTI. =20 This avoids BTI stubs in large executables where the PLTs have them already. An alternative is to never emit BTI stubs for PLTs, instead use BTI in the PLT if a library gets too big, however that may be more tricky given the ordering of PLT sizing and stub insertion. =20 Related to bug 30957. =20 (cherry picked from commit fc48504c7abe8eb9d9723632b2d53504927f46ff) Diff: --- bfd/elfnn-aarch64.c | 17 ++++++++++++++--- 1 file changed, 14 insertions(+), 3 deletions(-) diff --git a/bfd/elfnn-aarch64.c b/bfd/elfnn-aarch64.c index 3adece30250..4faf642b422 100644 --- a/bfd/elfnn-aarch64.c +++ b/bfd/elfnn-aarch64.c @@ -3675,7 +3675,8 @@ group_sections (struct elf_aarch64_link_hash_table *h= tab, /* True if the inserted stub does not break BTI compatibility. */ =20 static bool -aarch64_bti_stub_p (struct elf_aarch64_stub_hash_entry *stub_entry) +aarch64_bti_stub_p (struct bfd_link_info *info, + struct elf_aarch64_stub_hash_entry *stub_entry) { /* Stubs without indirect branch are BTI compatible. */ if (stub_entry->stub_type !=3D aarch64_stub_adrp_branch @@ -3684,12 +3685,22 @@ aarch64_bti_stub_p (struct elf_aarch64_stub_hash_en= try *stub_entry) =20 /* Return true if the target instruction is compatible with BR x16. */ =20 + struct elf_aarch64_link_hash_table *globals =3D elf_aarch64_hash_table (= info); asection *section =3D stub_entry->target_section; bfd_byte loc[4]; file_ptr off =3D stub_entry->target_value; bfd_size_type count =3D sizeof (loc); =20 - if (!bfd_get_section_contents (section->owner, section, loc, off, count)) + /* PLT code is not generated yet, so treat it specially. + Note: Checking elf_aarch64_obj_tdata.plt_type & PLT_BTI is not + enough because it only implies BTI in the PLT0 and tlsdesc PLT + entries. Normal PLT entries don't have BTI in a shared library + (because such PLT is normally not called indirectly and adding + the BTI when a stub targets a PLT would change the PLT layout + and it's too late for that here). */ + if (section =3D=3D globals->root.splt) + memcpy (loc, globals->plt_entry, count); + else if (!bfd_get_section_contents (section->owner, section, loc, off, c= ount)) return false; =20 uint32_t insn =3D bfd_getl32 (loc); @@ -4636,7 +4647,7 @@ _bfd_aarch64_add_call_stub_entries (bool *stub_change= d, bfd *output_bfd, =20 /* A stub with indirect jump may break BTI compatibility, so insert another stub with direct jump near the target then. */ - if (need_bti && !aarch64_bti_stub_p (stub_entry)) + if (need_bti && !aarch64_bti_stub_p (info, stub_entry)) { id_sec_bti =3D htab->stub_group[sym_sec->id].link_sec;