From: Yangyu Chen <cyy@cyyself.name>
To: Palmer Dabbelt <palmer@rivosinc.com>
Cc: libc-alpha@sourceware.org, kito.cheng@sifive.com,
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 14:50:44 +0800 [thread overview]
Message-ID: <tencent_1EE33A9F8E60BC76816335EE438C7F087906@qq.com> (raw)
In-Reply-To: <mhng-b09f06ce-b46f-41d2-8b1a-d2765799ed4a@palmer-ri-x1c9>
> On Oct 30, 2024, at 11:10, Palmer Dabbelt <palmer@rivosinc.com> wrote:
>
> On Tue, 29 Oct 2024 19:58:14 PDT (-0700), cyy@cyyself.name wrote:
>> Friendly ping.
>>
>> FYI, this bug can be reproduced through the steps outlined in the BZ #32269.
>>
>> Link: https://sourceware.org/bugzilla/show_bug.cgi?id=32269
>>
>> On 10/16/24 01:01, Yangyu Chen wrote:
>>> 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.
>
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 6:51 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 [this message]
2024-10-30 7:36 ` Kito Cheng
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=tencent_1EE33A9F8E60BC76816335EE438C7F087906@qq.com \
--to=cyy@cyyself.name \
--cc=kito.cheng@sifive.com \
--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).