From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mailbox.box.xen0n.name (mail.xen0n.name [115.28.160.31]) by sourceware.org (Postfix) with ESMTPS id 4F26A3858CDB for ; Thu, 16 Nov 2023 07:43:55 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 4F26A3858CDB Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=xen0n.name Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=xen0n.name ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 4F26A3858CDB Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=115.28.160.31 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1700120637; cv=none; b=NO+63Sed1VA1+CO8wc0wvCp7fdlsqVV+2ooof7XvFAc6NyAIC+NOsbBUxxlZbvbsFJNvZjUj+5oXZvZ+/jbBulRfyTlI6dpbgJW1IBhBy+Sdmsl1TXwNscERGrn1Uv6p7kLfGyZoYiXNr4FVFibeaiZEo1h9EQ2cvHWY5W0XaGs= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1700120637; c=relaxed/simple; bh=EZCvj87KhVE5Uj4YRFGAhYqG5Y4+TZzTqW4HlILQ1dA=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=P34rEQMJQRDjSb1CFMkUeHcXuXraTH9Ul0C+/jSUFhmZoIaL2R0Ryn5gn+tNc3NqN/LMmeqbD7O2GlSMOpp53TwFd8aeHKhGffiyXCephykUvSNVidnntdcwN0zHOfRHP+I6GcV0//vWL8VYI0EdJ4aG7NrPaD40B91NUwMmY5w= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=xen0n.name; s=mail; t=1700120601; bh=EZCvj87KhVE5Uj4YRFGAhYqG5Y4+TZzTqW4HlILQ1dA=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=PPR6R2c/J+5QAHE24C8Ne8oC2+I+yPFk5/30wVBz5awQe32FAoeX+PaMA8oLoMVEH lReWx3uQ/Z3H7v+6KSIVsJ/BJ50TfvUY+DYsGlxHOpcasPk6622X6zTP217nJdr2gH au2MMiUvhqlkcJH87lE/IrpDsSU1kgdXBZn4uCRw= Received: from [IPV6:240e:388:8d26:bf00:6f50:1e00:d62c:dcf9] (unknown [IPv6:240e:388:8d26:bf00:6f50:1e00:d62c:dcf9]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by mailbox.box.xen0n.name (Postfix) with ESMTPSA id 9D3BA600A6; Thu, 16 Nov 2023 15:43:21 +0800 (CST) Message-ID: <08376e92-4295-4aa6-aa93-ce4ab4eda5a8@xen0n.name> Date: Thu, 16 Nov 2023 15:43:21 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 4/6] LoongArch: Remove "elf_seg_map (info->output_bfd) == NULL" relaxation condition Content-Language: en-US To: mengqinggang , binutils@sourceware.org Cc: xuchenghua@loongson.cn, chenglulu@loongson.cn, liuzhensong@loongson.cn, xry111@xry111.site, i.swmail@xen0n.name, maskray@google.com References: <20231116062307.3292483-1-mengqinggang@loongson.cn> <20231116062307.3292483-5-mengqinggang@loongson.cn> From: WANG Xuerui In-Reply-To: <20231116062307.3292483-5-mengqinggang@loongson.cn> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-12.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 11/16/23 14:23, mengqinggang wrote: > This condition cause .so(shared object) can't be relaxed. "Previously the condition prevented shared objects from being relaxed." > Without this condition, we need to update program header size and .eh_frame_hdr > size before relaxation. "To remove the limitation, we need to ..." > --- > bfd/elfnn-loongarch.c | 24 ++++++++++++++++++++---- > ld/emultempl/loongarchelf.em | 18 ++++++++++++++++++ > 2 files changed, 38 insertions(+), 4 deletions(-) > > diff --git a/bfd/elfnn-loongarch.c b/bfd/elfnn-loongarch.c > index 7436a14441f..d331eefb8ac 100644 > --- a/bfd/elfnn-loongarch.c > +++ b/bfd/elfnn-loongarch.c > @@ -3738,7 +3738,7 @@ loongarch_relax_delete_bytes (bfd *abfd, > > /* Relax pcalau12i,addi.d => pcaddi. */ > static bool > -loongarch_relax_pcala_addi (bfd *abfd, asection *sec, > +loongarch_relax_pcala_addi (bfd *abfd, asection *sec, asection *sym_sec, > Elf_Internal_Rela *rel_hi, bfd_vma symval, > struct bfd_link_info *info, bool *again) > { > @@ -3747,7 +3747,23 @@ loongarch_relax_pcala_addi (bfd *abfd, asection *sec, > uint32_t pca = bfd_get (32, abfd, contents + rel_hi->r_offset); > uint32_t add = bfd_get (32, abfd, contents + rel_lo->r_offset); > uint32_t rd = pca & 0x1f; > + > + /* Because previous sections' relax, output_offset may increase and need to > + be updated before relax. But it update after relax in > + size_input_section defaultly, so we manually updating here. */ This is rather hard to understand... "This section's output_offset may change after previous section(s) have been relaxed, so it needs to be updated beforehand. size_input_section already took care of updating it after relaxation, so we additionally update once here." Does this sound okay? > + sec->output_offset = sec->output_section->size; > bfd_vma pc = sec_addr (sec) + rel_hi->r_offset; > + > + /* If pc and symbol not in the same segment, add/sub segment alignment. > + Fixme: if there are multiple readonly segments? */ Usually FIXME notes are spelled with all-caps to make it easier for the eyes and tools. > + if (!(sym_sec->flags & SEC_READONLY)) > + { > + if (symval > pc) > + pc -= info->maxpagesize; > + else if (symval < pc) > + pc += info->maxpagesize; > + } > + > const uint32_t addi_d = 0x02c00000; > const uint32_t pcaddi = 0x18000000; > > @@ -3889,7 +3905,6 @@ loongarch_elf_relax_section (bfd *abfd, asection *sec, > || sec->sec_flg0 > || (sec->flags & SEC_RELOC) == 0 > || sec->reloc_count == 0 > - || elf_seg_map (info->output_bfd) == NULL > || (info->disable_target_specific_optimizations > && info->relax_pass == 0) > /* The exp_seg_relro_adjust is enum phase_enum (0x4), > @@ -4009,14 +4024,15 @@ loongarch_elf_relax_section (bfd *abfd, asection *sec, > break; > case R_LARCH_PCALA_HI20: > if (0 == info->relax_pass && (i + 4) <= sec->reloc_count) > - loongarch_relax_pcala_addi (abfd, sec, rel, symval, info, again); > + loongarch_relax_pcala_addi (abfd, sec, sym_sec, rel, symval, > + info, again); > break; > case R_LARCH_GOT_PC_HI20: > if (local_got && 0 == info->relax_pass > && (i + 4) <= sec->reloc_count) > { > if (loongarch_relax_pcala_ld (abfd, sec, rel)) > - loongarch_relax_pcala_addi (abfd, sec, rel, symval, > + loongarch_relax_pcala_addi (abfd, sec, sym_sec, rel, symval, > info, again); > } > break; > diff --git a/ld/emultempl/loongarchelf.em b/ld/emultempl/loongarchelf.em > index 4850feb8767..d81c99da48b 100644 > --- a/ld/emultempl/loongarchelf.em > +++ b/ld/emultempl/loongarchelf.em > @@ -62,6 +62,24 @@ gld${EMULATION_NAME}_after_allocation (void) > } > } > > + /* The program header size of executable file may increase. */ > + if (bfd_get_flavour (link_info.output_bfd) == bfd_target_elf_flavour > + && !bfd_link_relocatable (&link_info)) > + { > + if (lang_phdr_list == NULL) > + elf_seg_map (link_info.output_bfd) = NULL; > + if (!_bfd_elf_map_sections_to_segments (link_info.output_bfd, > + &link_info, > + NULL)) > + einfo (_("%F%P: map sections to segments failed: %E\n")); > + } > + > + /* Adjust program header size and .eh_frame_hdr size before > + lang_relax_sections. Without it, the vma of data segment may increase. */ Out of curiosity (and unfamiliarity), is it only "increases" and no decreases? > + lang_do_assignments (lang_allocating_phase_enum); > + lang_reset_memory_regions (); > + lang_size_sections (NULL, true); > + > enum phase_enum *phase = &(expld.dataseg.phase); > bfd_elf${ELFSIZE}_loongarch_set_data_segment_info (&link_info, (int *) phase); > /* gld${EMULATION_NAME}_map_segments (need_layout); */