From: Xi Ruoyao <xry111@xry111.site>
To: binutils@sourceware.org
Cc: liuzhensong <liuzhensong@loongson.cn>,
WANG Xuerui <i.swmail@xen0n.name>,
caiyinyu <caiyinyu@loongson.cn>, Xi Ruoyao <xry111@xry111.site>
Subject: [PATCH] LoongArch: Use copy relocation for %pc_lo12 against external symbol
Date: Wed, 31 Aug 2022 21:22:59 +0800 [thread overview]
Message-ID: <20220831132259.71417-1-xry111@xry111.site> (raw)
We'd like to use PC-relative addressing instead of GOT for external
symbols in main executable images. This can improve code locality.
Doing so will need to implement copy relocation.
Despite there was a comment saying "Glibc does not support copy
relocation yet", I've run a very simple test and it seems copy
relocation is handled by ld.so without a problem:
pcalau12i $a1, %pc_hi20(stdout)
ld.d $a1, $a1, %pc_lo12(stdout)
pcalau12i $a0, %pc_hi20(msg)
addi.d $a0, $a0, %pc_lo12(msg)
pcalau12i $ra, %pc_hi20(fputs)
jirl $ra, $ra, %pc_lo12(fputs)
With this patch, R_LARCH_COPY is correctly emitted for "stdout" in
Glibc, and the test program runs and outputs "Hello world" in "msg"
successfully.
---
bfd/elfnn-loongarch.c | 93 ++++++++++++++++++++++++++++++++++++++-----
1 file changed, 84 insertions(+), 9 deletions(-)
diff --git a/bfd/elfnn-loongarch.c b/bfd/elfnn-loongarch.c
index ed42b8b6770..0cf24bd24d8 100644
--- a/bfd/elfnn-loongarch.c
+++ b/bfd/elfnn-loongarch.c
@@ -743,14 +743,26 @@ loongarch_elf_check_relocs (bfd *abfd, struct bfd_link_info *info,
h->non_got_ref = 1;
break;
- case R_LARCH_PCALA_HI20:
+ case R_LARCH_PCALA_LO12:
if (h != NULL)
{
- /* For pcalau12i + jirl. */
- h->needs_plt = 1;
- if (h->plt.refcount < 0)
- h->plt.refcount = 0;
- h->plt.refcount++;
+ /* Check if it's a jirl instruction. */
+ bfd_byte *contents = elf_section_data (sec)->this_hdr.contents;
+ uint32_t insn = 0;
+
+ if (contents || bfd_malloc_and_get_section (abfd, sec, &contents))
+ memcpy(&insn, contents + rel->r_offset, sizeof(insn));
+
+ if ((insn & 0xfc000000) == 0x4c000000)
+ {
+ /* For pcalau12i + jirl. */
+ h->needs_plt = 1;
+ if (h->plt.refcount < 0)
+ h->plt.refcount = 0;
+ h->plt.refcount++;
+ }
+ else
+ need_dynreloc = 1;
h->non_got_ref = 1;
h->pointer_equality_needed = 1;
@@ -949,7 +961,9 @@ loongarch_elf_adjust_dynamic_symbol (struct bfd_link_info *info,
struct elf_link_hash_entry *h)
{
struct loongarch_elf_link_hash_table *htab;
+ struct loongarch_elf_link_hash_entry *hent;
bfd *dynobj;
+ asection *s, *srel;
htab = loongarch_elf_hash_table (info);
BFD_ASSERT (htab != NULL);
@@ -999,9 +1013,52 @@ loongarch_elf_adjust_dynamic_symbol (struct bfd_link_info *info,
return true;
}
- /* R_LARCH_COPY is not adept glibc, not to generate. */
- /* Can not print anything, because make check ld. */
- return true;
+ /* If copy relocations is disabled via -z nocopyreloc, or we don't find any
+ dynamic relocs in read-only sections, avoid the copy reloc. */
+ if (info->nocopyreloc || !_bfd_elf_readonly_dynrelocs (h))
+ h->non_got_ref = 0;
+
+ if (!h->non_got_ref)
+ return true;
+
+ /* We must allocate the symbol in our .dynbss section, which will
+ become part of the .bss section of the executable. There will be
+ an entry for this symbol in the .dynsym section. The dynamic
+ object will contain position independent code, so all references
+ from the dynamic object to this symbol will go through the global
+ offset table. The dynamic linker will use the .dynsym entry to
+ determine the address it must put in the global offset table, so
+ both the dynamic object and the regular object will refer to the
+ same memory location for the variable. */
+
+ /* Generate a copy relocation to tell the dynamic linker to copy the
+ initial value out of the dynamic object and into the runtime process
+ image. We need to remember the offset into the .rel.bss section we
+ are going to use. */
+ hent = (struct loongarch_elf_link_hash_entry *) h;
+ if (hent->tls_type & ~GOT_NORMAL)
+ {
+ s = htab->sdyntdata;
+ srel = htab->elf.srelbss;
+ }
+ else if (h->root.u.def.section->flags & SEC_READONLY)
+ {
+ s = htab->elf.sdynrelro;
+ srel = htab->elf.sreldynrelro;
+ }
+ else
+ {
+ s = htab->elf.sdynbss;
+ srel = htab->elf.srelbss;
+ }
+
+ if ((h->root.u.def.section->flags & SEC_ALLOC) != 0 && h->size != 0)
+ {
+ srel->size += sizeof (ElfNN_External_Rela);
+ h->needs_copy = 1;
+ }
+
+ return _bfd_elf_adjust_dynamic_copy (info, h, s);
}
/* Allocate space in .plt, .got and associated reloc sections for
@@ -3702,6 +3759,24 @@ loongarch_elf_finish_dynamic_symbol (bfd *output_bfd,
loongarch_elf_append_rela (output_bfd, srela, &rela);
}
+ if (h->needs_copy)
+ {
+ Elf_Internal_Rela rela;
+ asection *s;
+
+ /* This symbols needs a copy reloc. Set it up. */
+ BFD_ASSERT (h->dynindx != -1);
+
+ rela.r_offset = sec_addr (h->root.u.def.section) + h->root.u.def.value;
+ rela.r_info = ELFNN_R_INFO (h->dynindx, R_LARCH_COPY);
+ rela.r_addend = 0;
+ if (h->root.u.def.section == htab->elf.sdynrelro)
+ s = htab->elf.sreldynrelro;
+ else
+ s = htab->elf.srelbss;
+ loongarch_elf_append_rela (output_bfd, s, &rela);
+ }
+
/* Mark some specially defined symbols as absolute. */
if (h == htab->elf.hdynamic || h == htab->elf.hgot || h == htab->elf.hplt)
sym->st_shndx = SHN_ABS;
--
2.37.0
next reply other threads:[~2022-08-31 13:23 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-31 13:22 Xi Ruoyao [this message]
2022-08-31 13:41 ` Xi Ruoyao
2022-09-01 1:38 ` liuzhensong
2022-09-01 1:38 ` liuzhensong
2022-09-01 2:12 ` Xi Ruoyao
2022-09-01 2:31 ` liuzhensong
2022-09-01 2:31 ` liuzhensong
2022-09-01 1:27 ` liuzhensong
2022-09-01 1:27 ` liuzhensong
2022-09-01 1:41 ` Xi Ruoyao
2022-09-01 2:09 ` liuzhensong
2022-09-01 7:42 ` 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=20220831132259.71417-1-xry111@xry111.site \
--to=xry111@xry111.site \
--cc=binutils@sourceware.org \
--cc=caiyinyu@loongson.cn \
--cc=i.swmail@xen0n.name \
--cc=liuzhensong@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).