From: WANG Xuerui <i.swmail@xen0n.name>
To: mengqinggang <mengqinggang@loongson.cn>, binutils@sourceware.org
Cc: xuchenghua@loongson.cn, chenglulu@loongson.cn,
liuzhensong@loongson.cn, xry111@xry111.site, i.swmail@xen0n.name,
maskray@google.com
Subject: Re: [PATCH v1 4/6] LoongArch: Remove "elf_seg_map (info->output_bfd) == NULL" relaxation condition
Date: Thu, 16 Nov 2023 15:43:21 +0800 [thread overview]
Message-ID: <08376e92-4295-4aa6-aa93-ce4ab4eda5a8@xen0n.name> (raw)
In-Reply-To: <20231116062307.3292483-5-mengqinggang@loongson.cn>
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); */
next prev parent reply other threads:[~2023-11-16 7:43 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-16 6:23 [PATCH v1 0/6] Fix some bugs of relaxation mengqinggang
2023-11-16 6:23 ` [PATCH v1 1/6] LoongArch: Fix ld --no-relax bug mengqinggang
2023-11-16 7:34 ` WANG Xuerui
2023-11-16 6:23 ` [PATCH v1 2/6] LoongArch: Directly delete relaxed instuctions in first relaxation pass mengqinggang
2023-11-16 6:23 ` [PATCH v1 3/6] LoongArch: Multiple relax_trip in one relax_pass mengqinggang
2023-11-16 6:23 ` [PATCH v1 4/6] LoongArch: Remove "elf_seg_map (info->output_bfd) == NULL" relaxation condition mengqinggang
2023-11-16 7:43 ` WANG Xuerui [this message]
2023-11-16 9:38 ` mengqinggang
2023-11-16 6:23 ` [PATCH v1 5/6] LoongArch: Modify link_info.relax_pass from 3 to 2 mengqinggang
2023-11-16 6:23 ` [PATCH v1 6/6] LoongArch: Add more relaxation testcases mengqinggang
2023-11-16 6:39 ` Fangrui Song
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=08376e92-4295-4aa6-aa93-ce4ab4eda5a8@xen0n.name \
--to=i.swmail@xen0n.name \
--cc=binutils@sourceware.org \
--cc=chenglulu@loongson.cn \
--cc=liuzhensong@loongson.cn \
--cc=maskray@google.com \
--cc=mengqinggang@loongson.cn \
--cc=xry111@xry111.site \
--cc=xuchenghua@loongson.cn \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).