public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
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;
>>>  }



  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).