From: Kito Cheng <kito.cheng@sifive.com>
To: Yangyu Chen <cyy@cyyself.name>
Cc: Palmer Dabbelt <palmer@rivosinc.com>,
libc-alpha@sourceware.org, vincent.chen@sifive.com,
schwab@suse.de
Subject: Re: [PATCH v2] RISC-V: Fix IFUNC resolver cannot access gp pointer
Date: Wed, 30 Oct 2024 15:36:11 +0800 [thread overview]
Message-ID: <CALLt3TjW1hpUS9ZJf+V_s+rO0FY7XYwxa+tGeJYzTDG6s+T_EQ@mail.gmail.com> (raw)
In-Reply-To: <tencent_1EE33A9F8E60BC76816335EE438C7F087906@qq.com>
Hi Palmer:
> >>> In some cases, an IFUNC resolver may need to access the gp pointer to
> >>> resolve the function address. Such an object may have l_relocated == 0.
> >>> In this case, the GP register will not be set up. Thus, the IFUNC
> >>> resolver cannot access the gp pointer. This patch fixes this issue by
> >>> relaxing the check of l_relocated in elf_machine_runtime_setup.
> >>>
> >>> As for the original Bug 31317, since the static-linked executable has
> >>> already set up the gp pointer, we don't need to execute the code to set
> >>> up the gp pointer again. I have also reproduced and checked Bug 31317,
> >>> this patch can fix the issue.
> >
> > We had a pretty similar issue with the hwprobe IFUNC stuff, and IIRC the result there was that it's just not safe to look up global symbols from an IFUNC.
Do you remember if there are any other issues that need to be resolved
other than the GP issue?
Or do you think it's not the right solution for the GP issue or it may
have potential risk?
> >
>
> However, using global variables in IFUNC is unavoidable when using
> the data structure __riscv_feature_bits from RISC-V C-API [1], which
> stores a global variable and is initialized by a function in libgcc
> (GCC) [2] or compiler-rt (LLVM) [3]. I encountered this bug while
> implementing target_clones and target_version for RISC-V GCC [4].
>
> I have no better idea to solve this problem. Perhaps we should add
> some new restrictions to the ABI?
>
> [1] https://github.com/riscv-non-isa/riscv-c-api-doc/blob/main/src/c-api.adoc#extension-bitmask
> [2] https://github.com/gcc-mirror/gcc/blob/master/libgcc/config/riscv/feature_bits.c
> [3] https://github.com/llvm/llvm-project/blob/main/compiler-rt/lib/builtins/cpu_model/riscv.c
> [4] https://patchwork.sourceware.org/project/gcc/list/?series=39863&state=*
>
> >>> Closes: BZ #32269
> >>> Fixes: 96d1b9ac23 ("RISC-V: Fix the static-PIE non-relocated object check")
> >>> Signed-off-by: Yangyu Chen <cyy@cyyself.name>
> >>> ---
> >>> sysdeps/riscv/dl-machine.h | 4 +++-
> >>> 1 file changed, 3 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git a/sysdeps/riscv/dl-machine.h b/sysdeps/riscv/dl-machine.h
> >>> index b2f28697f7..10a36d6701 100644
> >>> --- a/sysdeps/riscv/dl-machine.h
> >>> +++ b/sysdeps/riscv/dl-machine.h
> >>> @@ -348,7 +348,8 @@ elf_machine_runtime_setup (struct link_map *l, struct r_scope_elem *scope[],
> >>> gotplt[1] = (ElfW(Addr)) l;
> >>> }
> >>>
> >>> - if (l->l_type == lt_executable && l->l_relocated)
> >>> +#ifdef SHARED
> >>> + if (l->l_type == lt_executable)
> >>> {
> >>> /* The __global_pointer$ may not be defined by the linker if the
> >>> $gp register does not be used to access the global variable
> >>> @@ -368,6 +369,7 @@ elf_machine_runtime_setup (struct link_map *l, struct r_scope_elem *scope[],
> >>> : "r" (ref->st_value)
> >>> );
> >>> }
> >>> +#endif
> >>> #endif
> >>> return lazy;
> >>> }
>
>
next prev parent reply other threads:[~2024-10-30 7:36 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-15 17:01 Yangyu Chen
2024-10-30 2:58 ` Yangyu Chen
2024-10-30 3:10 ` Palmer Dabbelt
2024-10-30 6:50 ` Yangyu Chen
2024-10-30 7:36 ` Kito Cheng [this message]
2024-10-30 9:22 ` Florian Weimer
2024-10-30 10:26 ` Kito Cheng
2024-10-30 10:42 ` Florian Weimer
2024-10-30 10:48 ` Kito Cheng
2024-10-30 11:09 ` Florian Weimer
2024-10-30 18:28 ` Yangyu Chen
2024-10-31 10:07 ` Kito Cheng
2024-10-31 10:32 ` Florian Weimer
2024-10-31 10:35 ` Yangyu Chen
2024-10-31 10:51 ` Florian Weimer
2024-11-13 10:29 ` Yangyu Chen
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=CALLt3TjW1hpUS9ZJf+V_s+rO0FY7XYwxa+tGeJYzTDG6s+T_EQ@mail.gmail.com \
--to=kito.cheng@sifive.com \
--cc=cyy@cyyself.name \
--cc=libc-alpha@sourceware.org \
--cc=palmer@rivosinc.com \
--cc=schwab@suse.de \
--cc=vincent.chen@sifive.com \
/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).