* [PATCH] Allow memset local PLT reference for RISC-V.
@ 2020-06-22 21:10 Alistair Francis
2020-06-23 7:19 ` Andreas Schwab
2020-06-25 21:27 ` Palmer Dabbelt
0 siblings, 2 replies; 39+ messages in thread
From: Alistair Francis @ 2020-06-22 21:10 UTC (permalink / raw)
To: libc-alpha; +Cc: alistair23, Alistair Francis
This is similar to commit a26e2e9feab87d4f745c31411458b048742ac733
"Allow memset local PLT reference for powerpc soft-float.".
GCC 10.1 results in the localplt test failing for RISC-V.
From the original commit for power-pc:
Since memset is documented as a function GCC may always implicitly
generate calls to, it seems reasonable to allow that local PLT
reference (just like those for libgcc functions that GCC implicitly
generates calls to and that are also exported from libc.so), which
this patch does.
---
sysdeps/unix/sysv/linux/riscv/localplt.data | 1 +
1 file changed, 1 insertion(+)
diff --git a/sysdeps/unix/sysv/linux/riscv/localplt.data b/sysdeps/unix/sysv/linux/riscv/localplt.data
index 0ed8650b65..0a235592c3 100644
--- a/sysdeps/unix/sysv/linux/riscv/localplt.data
+++ b/sysdeps/unix/sysv/linux/riscv/localplt.data
@@ -5,6 +5,7 @@ libc.so: calloc
libc.so: free
libc.so: malloc
libc.so: memalign
+libc.so: memset ?
libc.so: realloc
# The TLS-enabled version of these functions is interposed from libc.so.
ld.so: _dl_signal_error
--
2.27.0
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH] Allow memset local PLT reference for RISC-V.
2020-06-22 21:10 [PATCH] Allow memset local PLT reference for RISC-V Alistair Francis
@ 2020-06-23 7:19 ` Andreas Schwab
2020-06-24 22:25 ` Alistair Francis
2020-06-25 0:20 ` Vineet Gupta
2020-06-25 21:27 ` Palmer Dabbelt
1 sibling, 2 replies; 39+ messages in thread
From: Andreas Schwab @ 2020-06-23 7:19 UTC (permalink / raw)
To: Alistair Francis via Libc-alpha; +Cc: Alistair Francis
On Jun 22 2020, Alistair Francis via Libc-alpha wrote:
> This is similar to commit a26e2e9feab87d4f745c31411458b048742ac733
> "Allow memset local PLT reference for powerpc soft-float.".
>
> GCC 10.1 results in the localplt test failing for RISC-V.
Why doesn't the redirect in sysdeps/generic/symbol-hacks.h work?
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH] Allow memset local PLT reference for RISC-V.
2020-06-23 7:19 ` Andreas Schwab
@ 2020-06-24 22:25 ` Alistair Francis
2020-06-25 7:20 ` Florian Weimer
2020-06-29 9:11 ` Florian Weimer
2020-06-25 0:20 ` Vineet Gupta
1 sibling, 2 replies; 39+ messages in thread
From: Alistair Francis @ 2020-06-24 22:25 UTC (permalink / raw)
To: Andreas Schwab; +Cc: Alistair Francis via Libc-alpha, Alistair Francis
On Tue, Jun 23, 2020 at 12:19 AM Andreas Schwab <schwab@linux-m68k.org> wrote:
>
> On Jun 22 2020, Alistair Francis via Libc-alpha wrote:
>
> > This is similar to commit a26e2e9feab87d4f745c31411458b048742ac733
> > "Allow memset local PLT reference for powerpc soft-float.".
> >
> > GCC 10.1 results in the localplt test failing for RISC-V.
>
> Why doesn't the redirect in sysdeps/generic/symbol-hacks.h work?
I'm not sure.
I suspect it's the same reason it didn't work in the commit this is
based off: a26e2e9feab87d4f745c31411458b048742ac733
"Allow memset local PLT reference for powerpc soft-float.".
The error is part of glibc's check scripts. I'm assuming memset is in
the binary which produces a check failure as we don't expect it to be.
I'm not sure where sysdeps/generic/symbol-hacks.h is involved in this
process though.
Alistair
>
> Andreas.
>
> --
> Andreas Schwab, schwab@linux-m68k.org
> GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
> "And now for something completely different."
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH] Allow memset local PLT reference for RISC-V.
2020-06-23 7:19 ` Andreas Schwab
2020-06-24 22:25 ` Alistair Francis
@ 2020-06-25 0:20 ` Vineet Gupta
1 sibling, 0 replies; 39+ messages in thread
From: Vineet Gupta @ 2020-06-25 0:20 UTC (permalink / raw)
To: Andreas Schwab, Alistair Francis via Libc-alpha; +Cc: Alistair Francis
On 6/23/20 12:19 AM, Andreas Schwab wrote:
> On Jun 22 2020, Alistair Francis via Libc-alpha wrote:
>
>> This is similar to commit a26e2e9feab87d4f745c31411458b048742ac733
>> "Allow memset local PLT reference for powerpc soft-float.".
>>
>> GCC 10.1 results in the localplt test failing for RISC-V.
>
> Why doesn't the redirect in sysdeps/generic/symbol-hacks.h work?
FWIW, for ARC port, Adhemerval suggested a similar workaround [1] but my stab at
it didn't work either [2]
[1] https://sourceware.org/pipermail/libc-alpha/2020-June/114838.html
[2] https://sourceware.org/pipermail/libc-alpha/2020-June/114911.html
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH] Allow memset local PLT reference for RISC-V.
2020-06-24 22:25 ` Alistair Francis
@ 2020-06-25 7:20 ` Florian Weimer
2020-06-25 18:16 ` Vineet Gupta
2020-06-29 9:11 ` Florian Weimer
1 sibling, 1 reply; 39+ messages in thread
From: Florian Weimer @ 2020-06-25 7:20 UTC (permalink / raw)
To: Alistair Francis via Libc-alpha
Cc: Andreas Schwab, Alistair Francis, Alistair Francis
* Alistair Francis via Libc-alpha:
> On Tue, Jun 23, 2020 at 12:19 AM Andreas Schwab <schwab@linux-m68k.org> wrote:
>>
>> On Jun 22 2020, Alistair Francis via Libc-alpha wrote:
>>
>> > This is similar to commit a26e2e9feab87d4f745c31411458b048742ac733
>> > "Allow memset local PLT reference for powerpc soft-float.".
>> >
>> > GCC 10.1 results in the localplt test failing for RISC-V.
>>
>> Why doesn't the redirect in sysdeps/generic/symbol-hacks.h work?
>
> I'm not sure.
Which function contains the memset PLT reference? “objdump
--disassemble --reloc” should show it. Does this function come from
libgcc, by chance?
Thanks,
Florian
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH] Allow memset local PLT reference for RISC-V.
2020-06-25 7:20 ` Florian Weimer
@ 2020-06-25 18:16 ` Vineet Gupta
2020-06-25 18:41 ` Florian Weimer
0 siblings, 1 reply; 39+ messages in thread
From: Vineet Gupta @ 2020-06-25 18:16 UTC (permalink / raw)
To: Florian Weimer, Alistair Francis via Libc-alpha
Cc: Alistair Francis, Andreas Schwab
On 6/25/20 12:20 AM, Florian Weimer via Libc-alpha wrote:
> * Alistair Francis via Libc-alpha:
>
>> On Tue, Jun 23, 2020 at 12:19 AM Andreas Schwab <schwab@linux-m68k.org> wrote:
>>>
>>> On Jun 22 2020, Alistair Francis via Libc-alpha wrote:
>>>
>>>> This is similar to commit a26e2e9feab87d4f745c31411458b048742ac733
>>>> "Allow memset local PLT reference for powerpc soft-float.".
>>>>
>>>> GCC 10.1 results in the localplt test failing for RISC-V.
>>>
>>> Why doesn't the redirect in sysdeps/generic/symbol-hacks.h work?
>>
>> I'm not sure.
>
> Which function contains the memset PLT reference? “objdump
> --disassemble --reloc” should show it. Does this function come from
> libgcc, by chance?
yes this is libgcc. I saw this on ARC too (with gcc 10)
1b2d0: ld r12,[pcl,0xe4d40] ;100010 <memset@@GLIBC_2.32+0x98c94>
1b2d8: j.d [r12]
1b2dc: mov r12,pcl
000366c8 <__mpn_mul>:
…
36748: bl.d -111736 ;1b2d0 <.plt+0x40>
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH] Allow memset local PLT reference for RISC-V.
2020-06-25 18:16 ` Vineet Gupta
@ 2020-06-25 18:41 ` Florian Weimer
2020-06-26 3:58 ` Vineet Gupta
0 siblings, 1 reply; 39+ messages in thread
From: Florian Weimer @ 2020-06-25 18:41 UTC (permalink / raw)
To: Vineet Gupta
Cc: Alistair Francis via Libc-alpha, Alistair Francis, Andreas Schwab
* Vineet Gupta:
> On 6/25/20 12:20 AM, Florian Weimer via Libc-alpha wrote:
>> * Alistair Francis via Libc-alpha:
>>
>>> On Tue, Jun 23, 2020 at 12:19 AM Andreas Schwab <schwab@linux-m68k.org> wrote:
>>>>
>>>> On Jun 22 2020, Alistair Francis via Libc-alpha wrote:
>>>>
>>>>> This is similar to commit a26e2e9feab87d4f745c31411458b048742ac733
>>>>> "Allow memset local PLT reference for powerpc soft-float.".
>>>>>
>>>>> GCC 10.1 results in the localplt test failing for RISC-V.
>>>>
>>>> Why doesn't the redirect in sysdeps/generic/symbol-hacks.h work?
>>>
>>> I'm not sure.
>>
>> Which function contains the memset PLT reference? “objdump
>> --disassemble --reloc” should show it. Does this function come from
>> libgcc, by chance?
>
> yes this is libgcc. I saw this on ARC too (with gcc 10)
>
> 1b2d0: ld r12,[pcl,0xe4d40] ;100010 <memset@@GLIBC_2.32+0x98c94>
> 1b2d8: j.d [r12]
> 1b2dc: mov r12,pcl
>
> 000366c8 <__mpn_mul>:
> …
> 36748: bl.d -111736 ;1b2d0 <.plt+0x40>
Uhm, how does this end up in libgcc?
Thanks,
Florian
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH] Allow memset local PLT reference for RISC-V.
2020-06-22 21:10 [PATCH] Allow memset local PLT reference for RISC-V Alistair Francis
2020-06-23 7:19 ` Andreas Schwab
@ 2020-06-25 21:27 ` Palmer Dabbelt
1 sibling, 0 replies; 39+ messages in thread
From: Palmer Dabbelt @ 2020-06-25 21:27 UTC (permalink / raw)
To: libc-alpha; +Cc: libc-alpha, Alistair Francis
On Mon, 22 Jun 2020 14:10:34 PDT (-0700), libc-alpha@sourceware.org wrote:
> This is similar to commit a26e2e9feab87d4f745c31411458b048742ac733
> "Allow memset local PLT reference for powerpc soft-float.".
>
> GCC 10.1 results in the localplt test failing for RISC-V.
>
> From the original commit for power-pc:
> Since memset is documented as a function GCC may always implicitly
> generate calls to, it seems reasonable to allow that local PLT
> reference (just like those for libgcc functions that GCC implicitly
> generates calls to and that are also exported from libc.so), which
> this patch does.
> ---
> sysdeps/unix/sysv/linux/riscv/localplt.data | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/sysdeps/unix/sysv/linux/riscv/localplt.data b/sysdeps/unix/sysv/linux/riscv/localplt.data
> index 0ed8650b65..0a235592c3 100644
> --- a/sysdeps/unix/sysv/linux/riscv/localplt.data
> +++ b/sysdeps/unix/sysv/linux/riscv/localplt.data
> @@ -5,6 +5,7 @@ libc.so: calloc
> libc.so: free
> libc.so: malloc
> libc.so: memalign
> +libc.so: memset ?
> libc.so: realloc
> # The TLS-enabled version of these functions is interposed from libc.so.
> ld.so: _dl_signal_error
Acked-by: Palmer Dabbelt <palmerdabbelt@google.com>
Thanks!
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH] Allow memset local PLT reference for RISC-V.
2020-06-25 18:41 ` Florian Weimer
@ 2020-06-26 3:58 ` Vineet Gupta
0 siblings, 0 replies; 39+ messages in thread
From: Vineet Gupta @ 2020-06-26 3:58 UTC (permalink / raw)
To: Florian Weimer
Cc: Alistair Francis, Andreas Schwab, Alistair Francis via Libc-alpha
On 6/25/20 11:41 AM, Florian Weimer via Libc-alpha wrote:
>>
>> 000366c8 <__mpn_mul>:
>> …
>> 36748: bl.d -111736 ;1b2d0 <.plt+0x40>
>
> Uhm, how does this end up in libgcc?
Never mind, I must not have been awoke when I wrote this. But I'm sure at some
point with gcc-10 I saw a memset PLT call, but now forget how it triggered.
-Vineet
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH] Allow memset local PLT reference for RISC-V.
2020-06-24 22:25 ` Alistair Francis
2020-06-25 7:20 ` Florian Weimer
@ 2020-06-29 9:11 ` Florian Weimer
2020-06-29 15:58 ` Alistair Francis
1 sibling, 1 reply; 39+ messages in thread
From: Florian Weimer @ 2020-06-29 9:11 UTC (permalink / raw)
To: Alistair Francis via Libc-alpha
Cc: Andreas Schwab, Alistair Francis, Alistair Francis
* Alistair Francis via Libc-alpha:
> On Tue, Jun 23, 2020 at 12:19 AM Andreas Schwab <schwab@linux-m68k.org> wrote:
>>
>> On Jun 22 2020, Alistair Francis via Libc-alpha wrote:
>>
>> > This is similar to commit a26e2e9feab87d4f745c31411458b048742ac733
>> > "Allow memset local PLT reference for powerpc soft-float.".
>> >
>> > GCC 10.1 results in the localplt test failing for RISC-V.
>>
>> Why doesn't the redirect in sysdeps/generic/symbol-hacks.h work?
>
> I'm not sure.
>
> I suspect it's the same reason it didn't work in the commit this is
> based off: a26e2e9feab87d4f745c31411458b048742ac733
> "Allow memset local PLT reference for powerpc soft-float.".
>
> The error is part of glibc's check scripts. I'm assuming memset is in
> the binary which produces a check failure as we don't expect it to be.
> I'm not sure where sysdeps/generic/symbol-hacks.h is involved in this
> process though.
Please post disassembly showing the location of the PLT calls. Which
functions have them?
Thanks,
Florian
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH] Allow memset local PLT reference for RISC-V.
2020-06-29 9:11 ` Florian Weimer
@ 2020-06-29 15:58 ` Alistair Francis
2020-06-29 16:00 ` Alistair Francis
2020-06-29 16:11 ` Florian Weimer
0 siblings, 2 replies; 39+ messages in thread
From: Alistair Francis @ 2020-06-29 15:58 UTC (permalink / raw)
To: Florian Weimer
Cc: Alistair Francis via Libc-alpha, Andreas Schwab, Alistair Francis
On Mon, Jun 29, 2020 at 2:11 AM Florian Weimer <fweimer@redhat.com> wrote:
>
> * Alistair Francis via Libc-alpha:
>
> > On Tue, Jun 23, 2020 at 12:19 AM Andreas Schwab <schwab@linux-m68k.org> wrote:
> >>
> >> On Jun 22 2020, Alistair Francis via Libc-alpha wrote:
> >>
> >> > This is similar to commit a26e2e9feab87d4f745c31411458b048742ac733
> >> > "Allow memset local PLT reference for powerpc soft-float.".
> >> >
> >> > GCC 10.1 results in the localplt test failing for RISC-V.
> >>
> >> Why doesn't the redirect in sysdeps/generic/symbol-hacks.h work?
> >
> > I'm not sure.
> >
> > I suspect it's the same reason it didn't work in the commit this is
> > based off: a26e2e9feab87d4f745c31411458b048742ac733
> > "Allow memset local PLT reference for powerpc soft-float.".
> >
> > The error is part of glibc's check scripts. I'm assuming memset is in
> > the binary which produces a check failure as we don't expect it to be.
> > I'm not sure where sysdeps/generic/symbol-hacks.h is involved in this
> > process though.
>
> Please post disassembly showing the location of the PLT calls. Which
> functions have them?
Sorry, I was waiting on my build to finish (I forgot to keep the
artifacts the first time).
I'm assuming you wanted the objdump of libc.a?
I see this (which I'm guessing is the PLT call) in libc.a
00000012 <.LVL4>:
*ptr++ = 0ul;
12: 00000097 auipc ra,0x0
12: R_RISCV_CALL memset
12: R_RISCV_RELAX *ABS*
16: 000080e7 jalr ra # 12 <.LVL4>
Which is called from the __sigblock() function.
Alistair
>
> Thanks,
> Florian
>
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH] Allow memset local PLT reference for RISC-V.
2020-06-29 15:58 ` Alistair Francis
@ 2020-06-29 16:00 ` Alistair Francis
2020-06-29 16:18 ` Florian Weimer
2020-06-29 16:11 ` Florian Weimer
1 sibling, 1 reply; 39+ messages in thread
From: Alistair Francis @ 2020-06-29 16:00 UTC (permalink / raw)
To: Florian Weimer
Cc: Alistair Francis via Libc-alpha, Andreas Schwab, Alistair Francis
On Mon, Jun 29, 2020 at 8:58 AM Alistair Francis <alistair23@gmail.com> wrote:
>
> On Mon, Jun 29, 2020 at 2:11 AM Florian Weimer <fweimer@redhat.com> wrote:
> >
> > * Alistair Francis via Libc-alpha:
> >
> > > On Tue, Jun 23, 2020 at 12:19 AM Andreas Schwab <schwab@linux-m68k.org> wrote:
> > >>
> > >> On Jun 22 2020, Alistair Francis via Libc-alpha wrote:
> > >>
> > >> > This is similar to commit a26e2e9feab87d4f745c31411458b048742ac733
> > >> > "Allow memset local PLT reference for powerpc soft-float.".
> > >> >
> > >> > GCC 10.1 results in the localplt test failing for RISC-V.
> > >>
> > >> Why doesn't the redirect in sysdeps/generic/symbol-hacks.h work?
> > >
> > > I'm not sure.
> > >
> > > I suspect it's the same reason it didn't work in the commit this is
> > > based off: a26e2e9feab87d4f745c31411458b048742ac733
> > > "Allow memset local PLT reference for powerpc soft-float.".
> > >
> > > The error is part of glibc's check scripts. I'm assuming memset is in
> > > the binary which produces a check failure as we don't expect it to be.
> > > I'm not sure where sysdeps/generic/symbol-hacks.h is involved in this
> > > process though.
> >
> > Please post disassembly showing the location of the PLT calls. Which
> > functions have them?
>
> Sorry, I was waiting on my build to finish (I forgot to keep the
> artifacts the first time).
>
> I'm assuming you wanted the objdump of libc.a?
>
> I see this (which I'm guessing is the PLT call) in libc.a
>
> 00000012 <.LVL4>:
> *ptr++ = 0ul;
> 12: 00000097 auipc ra,0x0
> 12: R_RISCV_CALL memset
> 12: R_RISCV_RELAX *ABS*
> 16: 000080e7 jalr ra # 12 <.LVL4>
>
> Which is called from the __sigblock() function.
Ah, I just checked libgcc, it has the memset PLT call:
0000020e <.L27>:
20e: 0605 addi a2,a2,1
210: 060a slli a2,a2,0x2
212: 4581 li a1,0
214: 00000097 auipc ra,0x0
214: R_RISCV_CALL_PLT memset
214: R_RISCV_RELAX *ABS*
218: 000080e7 jalr ra # 214 <.L27+0x6>
There are a few of them in libgcc.a as well.
Alistair
>
> Alistair
>
> >
> > Thanks,
> > Florian
> >
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH] Allow memset local PLT reference for RISC-V.
2020-06-29 15:58 ` Alistair Francis
2020-06-29 16:00 ` Alistair Francis
@ 2020-06-29 16:11 ` Florian Weimer
2020-06-29 16:15 ` Alistair Francis
1 sibling, 1 reply; 39+ messages in thread
From: Florian Weimer @ 2020-06-29 16:11 UTC (permalink / raw)
To: Alistair Francis
Cc: Alistair Francis via Libc-alpha, Andreas Schwab, Alistair Francis
* Alistair Francis:
> On Mon, Jun 29, 2020 at 2:11 AM Florian Weimer <fweimer@redhat.com> wrote:
>>
>> * Alistair Francis via Libc-alpha:
>>
>> > On Tue, Jun 23, 2020 at 12:19 AM Andreas Schwab <schwab@linux-m68k.org> wrote:
>> >>
>> >> On Jun 22 2020, Alistair Francis via Libc-alpha wrote:
>> >>
>> >> > This is similar to commit a26e2e9feab87d4f745c31411458b048742ac733
>> >> > "Allow memset local PLT reference for powerpc soft-float.".
>> >> >
>> >> > GCC 10.1 results in the localplt test failing for RISC-V.
>> >>
>> >> Why doesn't the redirect in sysdeps/generic/symbol-hacks.h work?
>> >
>> > I'm not sure.
>> >
>> > I suspect it's the same reason it didn't work in the commit this is
>> > based off: a26e2e9feab87d4f745c31411458b048742ac733
>> > "Allow memset local PLT reference for powerpc soft-float.".
>> >
>> > The error is part of glibc's check scripts. I'm assuming memset is in
>> > the binary which produces a check failure as we don't expect it to be.
>> > I'm not sure where sysdeps/generic/symbol-hacks.h is involved in this
>> > process though.
>>
>> Please post disassembly showing the location of the PLT calls. Which
>> functions have them?
>
> Sorry, I was waiting on my build to finish (I forgot to keep the
> artifacts the first time).
>
> I'm assuming you wanted the objdump of libc.a?
libc_pic.a. libc.a is built for static linking and does not use the
symbol hacks.
If the PLT reference comes from libgcc.a, it won't show up in
libc_pic.a, though. It will only be present in libc.so.
Thanks,
Florian
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH] Allow memset local PLT reference for RISC-V.
2020-06-29 16:11 ` Florian Weimer
@ 2020-06-29 16:15 ` Alistair Francis
2020-06-29 16:30 ` Florian Weimer
2020-06-29 17:00 ` Andreas Schwab
0 siblings, 2 replies; 39+ messages in thread
From: Alistair Francis @ 2020-06-29 16:15 UTC (permalink / raw)
To: Florian Weimer
Cc: Alistair Francis via Libc-alpha, Andreas Schwab, Alistair Francis
On Mon, Jun 29, 2020 at 9:12 AM Florian Weimer <fweimer@redhat.com> wrote:
>
> * Alistair Francis:
>
> > On Mon, Jun 29, 2020 at 2:11 AM Florian Weimer <fweimer@redhat.com> wrote:
> >>
> >> * Alistair Francis via Libc-alpha:
> >>
> >> > On Tue, Jun 23, 2020 at 12:19 AM Andreas Schwab <schwab@linux-m68k.org> wrote:
> >> >>
> >> >> On Jun 22 2020, Alistair Francis via Libc-alpha wrote:
> >> >>
> >> >> > This is similar to commit a26e2e9feab87d4f745c31411458b048742ac733
> >> >> > "Allow memset local PLT reference for powerpc soft-float.".
> >> >> >
> >> >> > GCC 10.1 results in the localplt test failing for RISC-V.
> >> >>
> >> >> Why doesn't the redirect in sysdeps/generic/symbol-hacks.h work?
> >> >
> >> > I'm not sure.
> >> >
> >> > I suspect it's the same reason it didn't work in the commit this is
> >> > based off: a26e2e9feab87d4f745c31411458b048742ac733
> >> > "Allow memset local PLT reference for powerpc soft-float.".
> >> >
> >> > The error is part of glibc's check scripts. I'm assuming memset is in
> >> > the binary which produces a check failure as we don't expect it to be.
> >> > I'm not sure where sysdeps/generic/symbol-hacks.h is involved in this
> >> > process though.
> >>
> >> Please post disassembly showing the location of the PLT calls. Which
> >> functions have them?
> >
> > Sorry, I was waiting on my build to finish (I forgot to keep the
> > artifacts the first time).
> >
> > I'm assuming you wanted the objdump of libc.a?
>
> libc_pic.a. libc.a is built for static linking and does not use the
> symbol hacks.
>
> If the PLT reference comes from libgcc.a, it won't show up in
> libc_pic.a, though. It will only be present in libc.so.
Ah ok.
There is also a PLT memset in libc_pic.a
1bc: 009aa023 sw s1,0(s5)
memset (result->__data, '\0',
1c0: 865e mv a2,s7
1c2: 4581 li a1,0
1c4: 008a8513 addi a0,s5,8
1c8: 00000097 auipc ra,0x0
1c8: R_RISCV_CALL_PLT __GI_memset
1c8: R_RISCV_RELAX *ABS*
1cc: 000080e7 jalr ra # 1c8 <.LVL39+0x14>
Alistair
>
> Thanks,
> Florian
>
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH] Allow memset local PLT reference for RISC-V.
2020-06-29 16:00 ` Alistair Francis
@ 2020-06-29 16:18 ` Florian Weimer
0 siblings, 0 replies; 39+ messages in thread
From: Florian Weimer @ 2020-06-29 16:18 UTC (permalink / raw)
To: Alistair Francis
Cc: Alistair Francis via Libc-alpha, Andreas Schwab, Alistair Francis
* Alistair Francis:
> Ah, I just checked libgcc, it has the memset PLT call:
>
> 0000020e <.L27>:
> 20e: 0605 addi a2,a2,1
> 210: 060a slli a2,a2,0x2
> 212: 4581 li a1,0
> 214: 00000097 auipc ra,0x0
> 214: R_RISCV_CALL_PLT memset
> 214: R_RISCV_RELAX *ABS*
> 218: 000080e7 jalr ra # 214 <.L27+0x6>
>
> There are a few of them in libgcc.a as well.
And that's linked into libc.so?
I would suggest to figure out the name of the function (not sure why
objdump doesn't print it in your case), and add that to the comment
localplt.data.
Thanks,
Florian
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH] Allow memset local PLT reference for RISC-V.
2020-06-29 16:30 ` Florian Weimer
@ 2020-06-29 16:25 ` Alistair Francis
2020-06-29 16:39 ` Florian Weimer
0 siblings, 1 reply; 39+ messages in thread
From: Alistair Francis @ 2020-06-29 16:25 UTC (permalink / raw)
To: Florian Weimer
Cc: Alistair Francis via Libc-alpha, Andreas Schwab, Alistair Francis
On Mon, Jun 29, 2020 at 9:30 AM Florian Weimer <fweimer@redhat.com> wrote:
>
> * Alistair Francis:
>
> > There is also a PLT memset in libc_pic.a
> >
> > 1bc: 009aa023 sw s1,0(s5)
> > memset (result->__data, '\0',
> > 1c0: 865e mv a2,s7
> > 1c2: 4581 li a1,0
> > 1c4: 008a8513 addi a0,s5,8
> > 1c8: 00000097 auipc ra,0x0
> > 1c8: R_RISCV_CALL_PLT __GI_memset
> > 1c8: R_RISCV_RELAX *ABS*
> > 1cc: 000080e7 jalr ra # 1c8 <.LVL39+0x14>
>
> That's weird. What does a direct call (to a hidden symbol) look like,
> relocation-wise.
I'm not sure. How can I figure out?
Alistair
>
> Thanks,
> Florian
>
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH] Allow memset local PLT reference for RISC-V.
2020-06-29 16:15 ` Alistair Francis
@ 2020-06-29 16:30 ` Florian Weimer
2020-06-29 16:25 ` Alistair Francis
2020-06-29 17:00 ` Andreas Schwab
1 sibling, 1 reply; 39+ messages in thread
From: Florian Weimer @ 2020-06-29 16:30 UTC (permalink / raw)
To: Alistair Francis
Cc: Alistair Francis via Libc-alpha, Andreas Schwab, Alistair Francis
* Alistair Francis:
> There is also a PLT memset in libc_pic.a
>
> 1bc: 009aa023 sw s1,0(s5)
> memset (result->__data, '\0',
> 1c0: 865e mv a2,s7
> 1c2: 4581 li a1,0
> 1c4: 008a8513 addi a0,s5,8
> 1c8: 00000097 auipc ra,0x0
> 1c8: R_RISCV_CALL_PLT __GI_memset
> 1c8: R_RISCV_RELAX *ABS*
> 1cc: 000080e7 jalr ra # 1c8 <.LVL39+0x14>
That's weird. What does a direct call (to a hidden symbol) look like,
relocation-wise.
Thanks,
Florian
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH] Allow memset local PLT reference for RISC-V.
2020-06-29 16:25 ` Alistair Francis
@ 2020-06-29 16:39 ` Florian Weimer
2020-06-29 16:39 ` Alistair Francis
0 siblings, 1 reply; 39+ messages in thread
From: Florian Weimer @ 2020-06-29 16:39 UTC (permalink / raw)
To: Alistair Francis
Cc: Alistair Francis via Libc-alpha, Andreas Schwab, Alistair Francis
* Alistair Francis:
> On Mon, Jun 29, 2020 at 9:30 AM Florian Weimer <fweimer@redhat.com> wrote:
>>
>> * Alistair Francis:
>>
>> > There is also a PLT memset in libc_pic.a
>> >
>> > 1bc: 009aa023 sw s1,0(s5)
>> > memset (result->__data, '\0',
>> > 1c0: 865e mv a2,s7
>> > 1c2: 4581 li a1,0
>> > 1c4: 008a8513 addi a0,s5,8
>> > 1c8: 00000097 auipc ra,0x0
>> > 1c8: R_RISCV_CALL_PLT __GI_memset
>> > 1c8: R_RISCV_RELAX *ABS*
>> > 1cc: 000080e7 jalr ra # 1c8 <.LVL39+0x14>
>>
>> That's weird. What does a direct call (to a hidden symbol) look like,
>> relocation-wise.
>
> I'm not sure. How can I figure out?
Look at different internal calls, e.g. __twalk_r and __libc_updwtmp (for
two variants, one with a hidden prototype and one without).
Thanks,
Florian
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH] Allow memset local PLT reference for RISC-V.
2020-06-29 16:39 ` Florian Weimer
@ 2020-06-29 16:39 ` Alistair Francis
2020-06-29 16:53 ` Florian Weimer
0 siblings, 1 reply; 39+ messages in thread
From: Alistair Francis @ 2020-06-29 16:39 UTC (permalink / raw)
To: Florian Weimer
Cc: Alistair Francis via Libc-alpha, Andreas Schwab, Alistair Francis
On Mon, Jun 29, 2020 at 9:39 AM Florian Weimer <fweimer@redhat.com> wrote:
>
> * Alistair Francis:
>
> > On Mon, Jun 29, 2020 at 9:30 AM Florian Weimer <fweimer@redhat.com> wrote:
> >>
> >> * Alistair Francis:
> >>
> >> > There is also a PLT memset in libc_pic.a
> >> >
> >> > 1bc: 009aa023 sw s1,0(s5)
> >> > memset (result->__data, '\0',
> >> > 1c0: 865e mv a2,s7
> >> > 1c2: 4581 li a1,0
> >> > 1c4: 008a8513 addi a0,s5,8
> >> > 1c8: 00000097 auipc ra,0x0
> >> > 1c8: R_RISCV_CALL_PLT __GI_memset
> >> > 1c8: R_RISCV_RELAX *ABS*
> >> > 1cc: 000080e7 jalr ra # 1c8 <.LVL39+0x14>
> >>
> >> That's weird. What does a direct call (to a hidden symbol) look like,
> >> relocation-wise.
> >
> > I'm not sure. How can I figure out?
>
> Look at different internal calls, e.g. __twalk_r and __libc_updwtmp (for
> two variants, one with a hidden prototype and one without).
Here is what I see from the libc_pic.a lib.
__twalk_r
00000000 *UND* 00000000 __GI___twalk_r
...
__twalk_r (loaded, do_release_shlib, handle);
1b2: 4088 lw a0,0(s1)
1b4: 8622 mv a2,s0
1b6: 00000597 auipc a1,0x0
1b6: R_RISCV_PCREL_HI20 do_release_shlib
1b6: R_RISCV_RELAX *ABS*
1ba: 00058593 mv a1,a1
1ba: R_RISCV_PCREL_LO12_I .L0
1ba: R_RISCV_RELAX *ABS*
1be: 00000097 auipc ra,0x0
1be: R_RISCV_CALL __GI___twalk_r
1be: R_RISCV_RELAX *ABS*
1c2: 000080e7 jalr ra # 1be <.L52+0xc>
__libc_updwtmp
000009c0 g F .text 00000124 .hidden __libc_updwtmp
...
00000064 <.LVL8>:
64: 0141 addi sp,sp,16
__libc_updwtmp (file_name, utmp);
66: 00000317 auipc t1,0x0
66: R_RISCV_CALL __libc_updwtmp
66: R_RISCV_RELAX *ABS*
6a: 00030067 jr t1 # 66 <.LVL8+0x2>
Alistair
>
> Thanks,
> Florian
>
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH] Allow memset local PLT reference for RISC-V.
2020-06-29 16:39 ` Alistair Francis
@ 2020-06-29 16:53 ` Florian Weimer
2020-06-29 17:01 ` Andreas Schwab
0 siblings, 1 reply; 39+ messages in thread
From: Florian Weimer @ 2020-06-29 16:53 UTC (permalink / raw)
To: Alistair Francis
Cc: Alistair Francis via Libc-alpha, Andreas Schwab, Alistair Francis
* Alistair Francis:
> On Mon, Jun 29, 2020 at 9:39 AM Florian Weimer <fweimer@redhat.com> wrote:
>>
>> * Alistair Francis:
>>
>> > On Mon, Jun 29, 2020 at 9:30 AM Florian Weimer <fweimer@redhat.com> wrote:
>> >>
>> >> * Alistair Francis:
>> >>
>> >> > There is also a PLT memset in libc_pic.a
>> >> >
>> >> > 1bc: 009aa023 sw s1,0(s5)
>> >> > memset (result->__data, '\0',
>> >> > 1c0: 865e mv a2,s7
>> >> > 1c2: 4581 li a1,0
>> >> > 1c4: 008a8513 addi a0,s5,8
>> >> > 1c8: 00000097 auipc ra,0x0
>> >> > 1c8: R_RISCV_CALL_PLT __GI_memset
>> >> > 1c8: R_RISCV_RELAX *ABS*
>> >> > 1cc: 000080e7 jalr ra # 1c8 <.LVL39+0x14>
>> >>
>> >> That's weird. What does a direct call (to a hidden symbol) look like,
>> >> relocation-wise.
>> >
>> > I'm not sure. How can I figure out?
>>
>> Look at different internal calls, e.g. __twalk_r and __libc_updwtmp (for
>> two variants, one with a hidden prototype and one without).
>
> Here is what I see from the libc_pic.a lib.
>
> __twalk_r
>
> 00000000 *UND* 00000000 __GI___twalk_r
> ...
> __twalk_r (loaded, do_release_shlib, handle);
> 1b2: 4088 lw a0,0(s1)
> 1b4: 8622 mv a2,s0
> 1b6: 00000597 auipc a1,0x0
> 1b6: R_RISCV_PCREL_HI20 do_release_shlib
> 1b6: R_RISCV_RELAX *ABS*
> 1ba: 00058593 mv a1,a1
> 1ba: R_RISCV_PCREL_LO12_I .L0
> 1ba: R_RISCV_RELAX *ABS*
> 1be: 00000097 auipc ra,0x0
> 1be: R_RISCV_CALL __GI___twalk_r
> 1be: R_RISCV_RELAX *ABS*
> 1c2: 000080e7 jalr ra # 1be <.L52+0xc>
>
> __libc_updwtmp
>
> 000009c0 g F .text 00000124 .hidden __libc_updwtmp
> ...
> 00000064 <.LVL8>:
> 64: 0141 addi sp,sp,16
> __libc_updwtmp (file_name, utmp);
> 66: 00000317 auipc t1,0x0
> 66: R_RISCV_CALL __libc_updwtmp
> 66: R_RISCV_RELAX *ABS*
> 6a: 00030067 jr t1 # 66 <.LVL8+0x2>
Okay, then the memcpy symbol hack does not work on RISC-V, and it's
worth fixing that.
It would be interesting to build iconv/gconv_open.c with --save-temps
and see what exactly ends up in the assembler file (and also what the
preprocessed sources look like).
Thanks,
Florian
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH] Allow memset local PLT reference for RISC-V.
2020-06-29 16:15 ` Alistair Francis
2020-06-29 16:30 ` Florian Weimer
@ 2020-06-29 17:00 ` Andreas Schwab
2020-06-29 17:13 ` Florian Weimer
1 sibling, 1 reply; 39+ messages in thread
From: Andreas Schwab @ 2020-06-29 17:00 UTC (permalink / raw)
To: Alistair Francis
Cc: Florian Weimer, Alistair Francis via Libc-alpha, Alistair Francis
On Jun 29 2020, Alistair Francis wrote:
> There is also a PLT memset in libc_pic.a
>
> 1bc: 009aa023 sw s1,0(s5)
> memset (result->__data, '\0',
> 1c0: 865e mv a2,s7
> 1c2: 4581 li a1,0
> 1c4: 008a8513 addi a0,s5,8
> 1c8: 00000097 auipc ra,0x0
> 1c8: R_RISCV_CALL_PLT __GI_memset
> 1c8: R_RISCV_RELAX *ABS*
> 1cc: 000080e7 jalr ra # 1c8 <.LVL39+0x14>
That will be relaxed by the linker.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH] Allow memset local PLT reference for RISC-V.
2020-06-29 16:53 ` Florian Weimer
@ 2020-06-29 17:01 ` Andreas Schwab
2020-06-29 17:05 ` Florian Weimer
0 siblings, 1 reply; 39+ messages in thread
From: Andreas Schwab @ 2020-06-29 17:01 UTC (permalink / raw)
To: Florian Weimer
Cc: Alistair Francis, Alistair Francis via Libc-alpha, Alistair Francis
On Jun 29 2020, Florian Weimer wrote:
> Okay, then the memcpy symbol hack does not work on RISC-V
Why do you think so?
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH] Allow memset local PLT reference for RISC-V.
2020-06-29 17:01 ` Andreas Schwab
@ 2020-06-29 17:05 ` Florian Weimer
2020-06-29 17:44 ` Andreas Schwab
2020-06-30 0:26 ` Jim Wilson
0 siblings, 2 replies; 39+ messages in thread
From: Florian Weimer @ 2020-06-29 17:05 UTC (permalink / raw)
To: Andreas Schwab
Cc: Alistair Francis, Alistair Francis via Libc-alpha, Alistair Francis
* Andreas Schwab:
> On Jun 29 2020, Florian Weimer wrote:
>
>> Okay, then the memcpy symbol hack does not work on RISC-V
>
> Why do you think so?
I think we should see R_RISCV_CALL instead of R_RISCV_CALL_PLT, like
here:
1be: 00000097 auipc ra,0x0
1be: R_RISCV_CALL __GI___twalk_r
1be: R_RISCV_RELAX *ABS*
Thanks,
Florian
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH] Allow memset local PLT reference for RISC-V.
2020-06-29 17:00 ` Andreas Schwab
@ 2020-06-29 17:13 ` Florian Weimer
2020-06-29 17:46 ` Andreas Schwab
0 siblings, 1 reply; 39+ messages in thread
From: Florian Weimer @ 2020-06-29 17:13 UTC (permalink / raw)
To: Andreas Schwab
Cc: Alistair Francis, Alistair Francis via Libc-alpha, Alistair Francis
* Andreas Schwab:
> On Jun 29 2020, Alistair Francis wrote:
>
>> There is also a PLT memset in libc_pic.a
>>
>> 1bc: 009aa023 sw s1,0(s5)
>> memset (result->__data, '\0',
>> 1c0: 865e mv a2,s7
>> 1c2: 4581 li a1,0
>> 1c4: 008a8513 addi a0,s5,8
>> 1c8: 00000097 auipc ra,0x0
>> 1c8: R_RISCV_CALL_PLT __GI_memset
>> 1c8: R_RISCV_RELAX *ABS*
>> 1cc: 000080e7 jalr ra # 1c8 <.LVL39+0x14>
>
> That will be relaxed by the linker.
But so far, the guidance has been *not* to rely on linker relaxation.
And as the __twalk_r shows, RISC-V actually has real local calls which
don't need linker relaxation. So I still think something is very
unusual with this target.
Thanks,
Florian
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH] Allow memset local PLT reference for RISC-V.
2020-06-29 17:05 ` Florian Weimer
@ 2020-06-29 17:44 ` Andreas Schwab
2020-06-30 0:26 ` Jim Wilson
1 sibling, 0 replies; 39+ messages in thread
From: Andreas Schwab @ 2020-06-29 17:44 UTC (permalink / raw)
To: Florian Weimer
Cc: Alistair Francis, Alistair Francis via Libc-alpha, Alistair Francis
On Jun 29 2020, Florian Weimer wrote:
> I think we should see R_RISCV_CALL instead of R_RISCV_CALL_PLT, like
> here:
No, the compiler doesn't know about our symbol hack.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH] Allow memset local PLT reference for RISC-V.
2020-06-29 17:13 ` Florian Weimer
@ 2020-06-29 17:46 ` Andreas Schwab
0 siblings, 0 replies; 39+ messages in thread
From: Andreas Schwab @ 2020-06-29 17:46 UTC (permalink / raw)
To: Florian Weimer
Cc: Alistair Francis, Alistair Francis via Libc-alpha, Alistair Francis
On Jun 29 2020, Florian Weimer wrote:
> But so far, the guidance has been *not* to rely on linker relaxation.
This is RISC-V, it does everything through linker relaxation.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH] Allow memset local PLT reference for RISC-V.
2020-06-29 17:05 ` Florian Weimer
2020-06-29 17:44 ` Andreas Schwab
@ 2020-06-30 0:26 ` Jim Wilson
2020-07-01 0:45 ` Maciej W. Rozycki
1 sibling, 1 reply; 39+ messages in thread
From: Jim Wilson @ 2020-06-30 0:26 UTC (permalink / raw)
To: Florian Weimer
Cc: Andreas Schwab, Alistair Francis, Alistair Francis via Libc-alpha
On Mon, Jun 29, 2020 at 10:05 AM Florian Weimer via Libc-alpha
<libc-alpha@sourceware.org> wrote:
> I think we should see R_RISCV_CALL instead of R_RISCV_CALL_PLT, like
> here:
There is a proposal to deprecate one of R_RISCV_CALL and
R_RISCV_CALL_PLT, because whether you get a call to a plt or not
depends on the symbol info, not the relocation type. We don't
actually need two different relocs for this. Old ABIs like x86 have
two relocs, but new ABIs like aarch64 have only one reloc for calls.
So it was a mistake in the RISC-V ABI to define two relocs. The LLVM
RISC-V port actually handles the two relocs exactly the same. GNU ld
handles them slightly differently, but that is something that needs to
be fixed when we deprecate one. I think that the RISC-V gcc port
always emits the R_RISCV_CALL_PLT reloc when PIC, and always emits
R_RISCV_CALL when not-PIC. Then the linker decides for
R_RISCV_CALL_PLT whether we actually need a plt or not.
Anyways, if you want to know where the PLT call is coming from, you
can't rely on the relocs. R_RISCV_CALL_PLT is not necessarily a plt
call.
Jim
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH] Allow memset local PLT reference for RISC-V.
2020-06-30 0:26 ` Jim Wilson
@ 2020-07-01 0:45 ` Maciej W. Rozycki
2020-07-10 21:35 ` Alistair Francis
0 siblings, 1 reply; 39+ messages in thread
From: Maciej W. Rozycki @ 2020-07-01 0:45 UTC (permalink / raw)
To: Jim Wilson
Cc: Florian Weimer, Alistair Francis,
Alistair Francis via Libc-alpha, Andreas Schwab
On Mon, 29 Jun 2020, Jim Wilson wrote:
> Anyways, if you want to know where the PLT call is coming from, you
> can't rely on the relocs. R_RISCV_CALL_PLT is not necessarily a plt
> call.
If a PLT entry has been created, then the linker must have considered the
symbol referred preemptible, whether legitimately or not.
Rather than scratching one's head I would suggest running the relevant LD
invocation under GDB to find out what really happens there, which may be
as easy as setting a breakpoint on `riscv_elf_finish_dynamic_symbol' with
the right condition on the hash entry so as to stop on `memset' only, and
then working backwards with a watchpoint (on a host system that does not
use ASLR) to find out what sets `h->plt.offset'. There'll be the answer.
HTH,
Maciej
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH] Allow memset local PLT reference for RISC-V.
2020-07-01 0:45 ` Maciej W. Rozycki
@ 2020-07-10 21:35 ` Alistair Francis
2020-07-10 22:34 ` H.J. Lu
2020-07-12 1:32 ` Maciej W. Rozycki
0 siblings, 2 replies; 39+ messages in thread
From: Alistair Francis @ 2020-07-10 21:35 UTC (permalink / raw)
To: Maciej W. Rozycki
Cc: Jim Wilson, Florian Weimer, Alistair Francis via Libc-alpha,
Andreas Schwab, Alistair Francis
On Tue, Jun 30, 2020 at 5:45 PM Maciej W. Rozycki via Libc-alpha
<libc-alpha@sourceware.org> wrote:
>
> On Mon, 29 Jun 2020, Jim Wilson wrote:
>
> > Anyways, if you want to know where the PLT call is coming from, you
> > can't rely on the relocs. R_RISCV_CALL_PLT is not necessarily a plt
> > call.
>
> If a PLT entry has been created, then the linker must have considered the
> symbol referred preemptible, whether legitimately or not.
>
> Rather than scratching one's head I would suggest running the relevant LD
> invocation under GDB to find out what really happens there, which may be
> as easy as setting a breakpoint on `riscv_elf_finish_dynamic_symbol' with
> the right condition on the hash entry so as to stop on `memset' only, and
> then working backwards with a watchpoint (on a host system that does not
> use ASLR) to find out what sets `h->plt.offset'. There'll be the answer.
I tried to look into this but haven't made much progress here. If
anyone has more ideas they would be very welcome otherwise I'll keep
digging into this.
Alistair
>
> HTH,
>
> Maciej
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH] Allow memset local PLT reference for RISC-V.
2020-07-10 21:35 ` Alistair Francis
@ 2020-07-10 22:34 ` H.J. Lu
2020-07-12 1:32 ` Maciej W. Rozycki
1 sibling, 0 replies; 39+ messages in thread
From: H.J. Lu @ 2020-07-10 22:34 UTC (permalink / raw)
To: Alistair Francis
Cc: Maciej W. Rozycki, Florian Weimer, Andreas Schwab,
Alistair Francis, Alistair Francis via Libc-alpha
On Fri, Jul 10, 2020 at 2:45 PM Alistair Francis via Libc-alpha
<libc-alpha@sourceware.org> wrote:
>
> On Tue, Jun 30, 2020 at 5:45 PM Maciej W. Rozycki via Libc-alpha
> <libc-alpha@sourceware.org> wrote:
> >
> > On Mon, 29 Jun 2020, Jim Wilson wrote:
> >
> > > Anyways, if you want to know where the PLT call is coming from, you
> > > can't rely on the relocs. R_RISCV_CALL_PLT is not necessarily a plt
> > > call.
> >
> > If a PLT entry has been created, then the linker must have considered the
> > symbol referred preemptible, whether legitimately or not.
> >
> > Rather than scratching one's head I would suggest running the relevant LD
> > invocation under GDB to find out what really happens there, which may be
> > as easy as setting a breakpoint on `riscv_elf_finish_dynamic_symbol' with
> > the right condition on the hash entry so as to stop on `memset' only, and
> > then working backwards with a watchpoint (on a host system that does not
> > use ASLR) to find out what sets `h->plt.offset'. There'll be the answer.
>
> I tried to look into this but haven't made much progress here. If
> anyone has more ideas they would be very welcome otherwise I'll keep
> digging into this.
>
It may be related to:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67220
--
H.J.
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH] Allow memset local PLT reference for RISC-V.
2020-07-10 21:35 ` Alistair Francis
2020-07-10 22:34 ` H.J. Lu
@ 2020-07-12 1:32 ` Maciej W. Rozycki
2020-07-14 2:07 ` RISC-V: `ld.so' fails linking against `libgcc.a' built at `-O0' (was: Re: [PATCH] Allow memset local PLT reference for RISC-V.) Maciej W. Rozycki
2020-08-20 22:39 ` [PATCH] Allow memset local PLT reference for RISC-V Alistair Francis
1 sibling, 2 replies; 39+ messages in thread
From: Maciej W. Rozycki @ 2020-07-12 1:32 UTC (permalink / raw)
To: Alistair Francis
Cc: Jim Wilson, Florian Weimer, Alistair Francis via Libc-alpha,
Andreas Schwab, Alistair Francis
On Fri, 10 Jul 2020, Alistair Francis wrote:
> > > Anyways, if you want to know where the PLT call is coming from, you
> > > can't rely on the relocs. R_RISCV_CALL_PLT is not necessarily a plt
> > > call.
> >
> > If a PLT entry has been created, then the linker must have considered the
> > symbol referred preemptible, whether legitimately or not.
> >
> > Rather than scratching one's head I would suggest running the relevant LD
> > invocation under GDB to find out what really happens there, which may be
> > as easy as setting a breakpoint on `riscv_elf_finish_dynamic_symbol' with
> > the right condition on the hash entry so as to stop on `memset' only, and
> > then working backwards with a watchpoint (on a host system that does not
> > use ASLR) to find out what sets `h->plt.offset'. There'll be the answer.
>
> I tried to look into this but haven't made much progress here. If
> anyone has more ideas they would be very welcome otherwise I'll keep
> digging into this.
The `h->needs_plt' flag is set by this `riscv_elf_check_relocs' code in
bfd/elfnn-riscv.c:
case R_RISCV_CALL_PLT:
/* This symbol requires a procedure linkage table entry. We
actually build the entry in adjust_dynamic_symbol,
because this might be a case of linking PIC code without
linking in any dynamic objects, in which case we don't
need to generate a procedure linkage table after all. */
if (h != NULL)
{
h->needs_plt = 1;
h->plt.refcount += 1;
}
break;
due to a reference from `addtf3.o', from `libgcc.a'. There are further 20
references for a total of 21. There is a later opportunity for the flag
to be cleared in `riscv_elf_adjust_dynamic_symbol', as observed in the
comment, however that only happens for symbols that bind locally, or which
are not referenced, and for `memset' obviously neither is the case (and
`allocate_dynrelocs' sets `h->plt.offset' in place of `h->plt.refcount'
then).
I don't think we have a way to redirect the reference to `__GI_memset'.
Maciej
^ permalink raw reply [flat|nested] 39+ messages in thread
* RISC-V: `ld.so' fails linking against `libgcc.a' built at `-O0' (was: Re: [PATCH] Allow memset local PLT reference for RISC-V.)
2020-07-12 1:32 ` Maciej W. Rozycki
@ 2020-07-14 2:07 ` Maciej W. Rozycki
2020-07-14 5:21 ` RISC-V: `ld.so' fails linking against `libgcc.a' built at `-O0' Andreas Schwab
2020-08-20 22:39 ` [PATCH] Allow memset local PLT reference for RISC-V Alistair Francis
1 sibling, 1 reply; 39+ messages in thread
From: Maciej W. Rozycki @ 2020-07-14 2:07 UTC (permalink / raw)
To: Alistair Francis
Cc: Jim Wilson, Florian Weimer, Andreas Schwab, Alistair Francis,
libc-alpha, gcc
On Sun, 12 Jul 2020, Maciej W. Rozycki wrote:
> I don't think we have a way to redirect the reference to `__GI_memset'.
Additionally, I need to mention that where `libgcc.a' has been built at
`-O0', RV32 `ld.so' fails linking due to unresolved `malloc' and `free'
references from numerous `libgcc.a' objects. This is because those
objects pull in the exception unwinder; specifically `__divdi3',
`__moddi3', and `__umoddi3' all include a call to `_Unwind_Resume' each.
Arguably this might probably be called a deficiency in libgcc, however
the objects are built with `-fexceptions -fnon-call-exceptions' and at
`-O0' GCC might not be able to see through code that no exception may
happen there. Therefore I am not sure offhand if this needs to be
considered a GCC or glibc bug.
Maciej
.../bin/../lib/gcc/riscv64-linux-gnu/10.0.1/../../../../riscv64-linux-gnu/bin/ld: .../obj/glibc-boot/ilp32/elf/librtld.os: in function `init_dwarf_reg_size_table':
.../src/gcc/libgcc/unwind-dw2.c:1572: undefined reference to `malloc'
.../bin/../lib/gcc/riscv64-linux-gnu/10.0.1/../../../../riscv64-linux-gnu/bin/ld: .../obj/glibc-boot/ilp32/elf/librtld.os: in function `uw_init_context_1':
.../src/gcc/libgcc/unwind-dw2.c:1613: undefined reference to `malloc'
.../bin/../lib/gcc/riscv64-linux-gnu/10.0.1/../../../../riscv64-linux-gnu/bin/ld: .../obj/glibc-boot/ilp32/elf/librtld.os: in function `uw_install_context_1':
.../src/gcc/libgcc/unwind-dw2.c:1694: undefined reference to `free'
.../bin/../lib/gcc/riscv64-linux-gnu/10.0.1/../../../../riscv64-linux-gnu/bin/ld: .../src/gcc/libgcc/unwind-dw2.c:1711: undefined reference to `free'
.../bin/../lib/gcc/riscv64-linux-gnu/10.0.1/../../../../riscv64-linux-gnu/bin/ld: .../obj/glibc-boot/ilp32/elf/librtld.os: in function `_Unwind_ForcedUnwind_Phase2':
.../src/gcc/libgcc/unwind.inc:152: undefined reference to `malloc'
.../bin/../lib/gcc/riscv64-linux-gnu/10.0.1/../../../../riscv64-linux-gnu/bin/ld: .../src/gcc/libgcc/unwind.inc:163: undefined reference to `malloc'
.../bin/../lib/gcc/riscv64-linux-gnu/10.0.1/../../../../riscv64-linux-gnu/bin/ld: .../obj/glibc-boot/ilp32/elf/librtld.os: in function `_Unwind_DeleteException':
.../src/gcc/libgcc/unwind.inc:281: undefined reference to `free'
collect2: error: ld returned 1 exit status
Makefile:554: recipe for target '.../obj/glibc-boot/ilp32/elf/ld.so' failed
make[2]: *** [.../obj/glibc-boot/ilp32/elf/ld.so] Error 1
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: RISC-V: `ld.so' fails linking against `libgcc.a' built at `-O0'
2020-07-14 2:07 ` RISC-V: `ld.so' fails linking against `libgcc.a' built at `-O0' (was: Re: [PATCH] Allow memset local PLT reference for RISC-V.) Maciej W. Rozycki
@ 2020-07-14 5:21 ` Andreas Schwab
2020-07-14 6:27 ` Richard Biener
0 siblings, 1 reply; 39+ messages in thread
From: Andreas Schwab @ 2020-07-14 5:21 UTC (permalink / raw)
To: Maciej W. Rozycki
Cc: Alistair Francis, Jim Wilson, Florian Weimer, Alistair Francis,
libc-alpha, gcc
On Jul 14 2020, Maciej W. Rozycki wrote:
> Arguably this might probably be called a deficiency in libgcc, however
> the objects are built with `-fexceptions -fnon-call-exceptions'
I consider that broken. It doesn't make any sense to build a lowlevel
runtime library like libgcc with exceptions.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: RISC-V: `ld.so' fails linking against `libgcc.a' built at `-O0'
2020-07-14 5:21 ` RISC-V: `ld.so' fails linking against `libgcc.a' built at `-O0' Andreas Schwab
@ 2020-07-14 6:27 ` Richard Biener
2020-07-14 9:35 ` Maciej W. Rozycki
0 siblings, 1 reply; 39+ messages in thread
From: Richard Biener @ 2020-07-14 6:27 UTC (permalink / raw)
To: Andreas Schwab
Cc: Maciej W. Rozycki, Florian Weimer, GCC Development,
GNU C Library, Alistair Francis, Alistair Francis
On Tue, Jul 14, 2020 at 7:24 AM Andreas Schwab <schwab@linux-m68k.org> wrote:
>
> On Jul 14 2020, Maciej W. Rozycki wrote:
>
> > Arguably this might probably be called a deficiency in libgcc, however
> > the objects are built with `-fexceptions -fnon-call-exceptions'
>
> I consider that broken. It doesn't make any sense to build a lowlevel
> runtime library like libgcc with exceptions.
Indeed - you only need to be able to unwind through those, so
-fasynchronous-unwind-tables should be used.
Richard.
> Andreas.
>
> --
> Andreas Schwab, schwab@linux-m68k.org
> GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
> "And now for something completely different."
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: RISC-V: `ld.so' fails linking against `libgcc.a' built at `-O0'
2020-07-14 6:27 ` Richard Biener
@ 2020-07-14 9:35 ` Maciej W. Rozycki
0 siblings, 0 replies; 39+ messages in thread
From: Maciej W. Rozycki @ 2020-07-14 9:35 UTC (permalink / raw)
To: Richard Biener
Cc: Andreas Schwab, Florian Weimer, GCC Development, GNU C Library,
Alistair Francis, Alistair Francis
On Tue, 14 Jul 2020, Richard Biener wrote:
> > > Arguably this might probably be called a deficiency in libgcc, however
> > > the objects are built with `-fexceptions -fnon-call-exceptions'
> >
> > I consider that broken. It doesn't make any sense to build a lowlevel
> > runtime library like libgcc with exceptions.
>
> Indeed - you only need to be able to unwind through those, so
> -fasynchronous-unwind-tables should be used.
This is libgcc's default however, only overridden for a couple of ARM
targets, for the very reason to avoid pulling in the unwinder, according
to the associated comments. This was added with commit fc6aa0a98a0c some
3 months before commit b932f770f70d added `-fasynchronous-unwind-tables'
as a supported compiler option, all back in 2001, so we've had it for
quite a while now.
The RISC-V target doesn't appear to produce any division overflow traps,
which would necessarily have to be arranged by a software convention like
with, say, the MIPS target, as the relevant hardware instructions do not
trigger an exception under any conditions.
By switching to `-fasynchronous-unwind-tables' the ARM override can also
go presumably, right?
Maciej
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH] Allow memset local PLT reference for RISC-V.
2020-07-12 1:32 ` Maciej W. Rozycki
2020-07-14 2:07 ` RISC-V: `ld.so' fails linking against `libgcc.a' built at `-O0' (was: Re: [PATCH] Allow memset local PLT reference for RISC-V.) Maciej W. Rozycki
@ 2020-08-20 22:39 ` Alistair Francis
2020-08-21 10:44 ` Maciej W. Rozycki
1 sibling, 1 reply; 39+ messages in thread
From: Alistair Francis @ 2020-08-20 22:39 UTC (permalink / raw)
To: Maciej W. Rozycki
Cc: Jim Wilson, Florian Weimer, Alistair Francis via Libc-alpha,
Andreas Schwab, Alistair Francis
On Sat, Jul 11, 2020 at 6:32 PM Maciej W. Rozycki <macro@wdc.com> wrote:
>
> On Fri, 10 Jul 2020, Alistair Francis wrote:
>
> > > > Anyways, if you want to know where the PLT call is coming from, you
> > > > can't rely on the relocs. R_RISCV_CALL_PLT is not necessarily a plt
> > > > call.
> > >
> > > If a PLT entry has been created, then the linker must have considered the
> > > symbol referred preemptible, whether legitimately or not.
> > >
> > > Rather than scratching one's head I would suggest running the relevant LD
> > > invocation under GDB to find out what really happens there, which may be
> > > as easy as setting a breakpoint on `riscv_elf_finish_dynamic_symbol' with
> > > the right condition on the hash entry so as to stop on `memset' only, and
> > > then working backwards with a watchpoint (on a host system that does not
> > > use ASLR) to find out what sets `h->plt.offset'. There'll be the answer.
> >
> > I tried to look into this but haven't made much progress here. If
> > anyone has more ideas they would be very welcome otherwise I'll keep
> > digging into this.
>
> The `h->needs_plt' flag is set by this `riscv_elf_check_relocs' code in
> bfd/elfnn-riscv.c:
>
> case R_RISCV_CALL_PLT:
> /* This symbol requires a procedure linkage table entry. We
> actually build the entry in adjust_dynamic_symbol,
> because this might be a case of linking PIC code without
> linking in any dynamic objects, in which case we don't
> need to generate a procedure linkage table after all. */
>
> if (h != NULL)
> {
> h->needs_plt = 1;
> h->plt.refcount += 1;
> }
> break;
>
> due to a reference from `addtf3.o', from `libgcc.a'. There are further 20
> references for a total of 21. There is a later opportunity for the flag
> to be cleared in `riscv_elf_adjust_dynamic_symbol', as observed in the
> comment, however that only happens for symbols that bind locally, or which
> are not referenced, and for `memset' obviously neither is the case (and
> `allocate_dynrelocs' sets `h->plt.offset' in place of `h->plt.refcount'
> then).
>
> I don't think we have a way to redirect the reference to `__GI_memset'.
I'm not really clear where this ended up. I have a session at Plumbers
next week to discuss the RV32 port and am planning on discussing this
issue as well.
It would be great if as many people as possible could be there.
https://linuxplumbersconf.org/event/7/contributions/809/
Alistair
>
> Maciej
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH] Allow memset local PLT reference for RISC-V.
2020-08-20 22:39 ` [PATCH] Allow memset local PLT reference for RISC-V Alistair Francis
@ 2020-08-21 10:44 ` Maciej W. Rozycki
2020-08-27 18:31 ` Alistair Francis
0 siblings, 1 reply; 39+ messages in thread
From: Maciej W. Rozycki @ 2020-08-21 10:44 UTC (permalink / raw)
To: Alistair Francis
Cc: Jim Wilson, Florian Weimer, Alistair Francis via Libc-alpha,
Andreas Schwab, Alistair Francis
On Thu, 20 Aug 2020, Alistair Francis wrote:
> > The `h->needs_plt' flag is set by this `riscv_elf_check_relocs' code in
> > bfd/elfnn-riscv.c:
> >
> > case R_RISCV_CALL_PLT:
> > /* This symbol requires a procedure linkage table entry. We
> > actually build the entry in adjust_dynamic_symbol,
> > because this might be a case of linking PIC code without
> > linking in any dynamic objects, in which case we don't
> > need to generate a procedure linkage table after all. */
> >
> > if (h != NULL)
> > {
> > h->needs_plt = 1;
> > h->plt.refcount += 1;
> > }
> > break;
> >
> > due to a reference from `addtf3.o', from `libgcc.a'. There are further 20
> > references for a total of 21. There is a later opportunity for the flag
> > to be cleared in `riscv_elf_adjust_dynamic_symbol', as observed in the
> > comment, however that only happens for symbols that bind locally, or which
> > are not referenced, and for `memset' obviously neither is the case (and
> > `allocate_dynrelocs' sets `h->plt.offset' in place of `h->plt.refcount'
> > then).
> >
> > I don't think we have a way to redirect the reference to `__GI_memset'.
>
> I'm not really clear where this ended up. I have a session at Plumbers
> next week to discuss the RV32 port and am planning on discussing this
> issue as well.
This: <https://sourceware.org/pipermail/binutils/2020-August/112750.html>
ought to sort it AFAICT.
Maciej
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH] Allow memset local PLT reference for RISC-V.
2020-08-21 10:44 ` Maciej W. Rozycki
@ 2020-08-27 18:31 ` Alistair Francis
2020-09-12 21:51 ` Alistair Francis
0 siblings, 1 reply; 39+ messages in thread
From: Alistair Francis @ 2020-08-27 18:31 UTC (permalink / raw)
To: Maciej W. Rozycki
Cc: Jim Wilson, Florian Weimer, Alistair Francis via Libc-alpha,
Andreas Schwab, Alistair Francis
On Fri, Aug 21, 2020 at 3:44 AM Maciej W. Rozycki <macro@wdc.com> wrote:
>
> On Thu, 20 Aug 2020, Alistair Francis wrote:
>
> > > The `h->needs_plt' flag is set by this `riscv_elf_check_relocs' code in
> > > bfd/elfnn-riscv.c:
> > >
> > > case R_RISCV_CALL_PLT:
> > > /* This symbol requires a procedure linkage table entry. We
> > > actually build the entry in adjust_dynamic_symbol,
> > > because this might be a case of linking PIC code without
> > > linking in any dynamic objects, in which case we don't
> > > need to generate a procedure linkage table after all. */
> > >
> > > if (h != NULL)
> > > {
> > > h->needs_plt = 1;
> > > h->plt.refcount += 1;
> > > }
> > > break;
> > >
> > > due to a reference from `addtf3.o', from `libgcc.a'. There are further 20
> > > references for a total of 21. There is a later opportunity for the flag
> > > to be cleared in `riscv_elf_adjust_dynamic_symbol', as observed in the
> > > comment, however that only happens for symbols that bind locally, or which
> > > are not referenced, and for `memset' obviously neither is the case (and
> > > `allocate_dynrelocs' sets `h->plt.offset' in place of `h->plt.refcount'
> > > then).
> > >
> > > I don't think we have a way to redirect the reference to `__GI_memset'.
> >
> > I'm not really clear where this ended up. I have a session at Plumbers
> > next week to discuss the RV32 port and am planning on discussing this
> > issue as well.
>
> This: <https://sourceware.org/pipermail/binutils/2020-August/112750.html>
> ought to sort it AFAICT.
Thanks!
This was discussed in the RISC-V Plumbers session yesterday and the
decision was made to just ignore this failure and wait for the
binutils patch.
Alistair
>
> Maciej
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH] Allow memset local PLT reference for RISC-V.
2020-08-27 18:31 ` Alistair Francis
@ 2020-09-12 21:51 ` Alistair Francis
0 siblings, 0 replies; 39+ messages in thread
From: Alistair Francis @ 2020-09-12 21:51 UTC (permalink / raw)
To: Maciej W. Rozycki
Cc: Jim Wilson, Florian Weimer, Alistair Francis via Libc-alpha,
Andreas Schwab, Alistair Francis
On Thu, Aug 27, 2020 at 11:31 AM Alistair Francis <alistair23@gmail.com> wrote:
>
> On Fri, Aug 21, 2020 at 3:44 AM Maciej W. Rozycki <macro@wdc.com> wrote:
> >
> > On Thu, 20 Aug 2020, Alistair Francis wrote:
> >
> > > > The `h->needs_plt' flag is set by this `riscv_elf_check_relocs' code in
> > > > bfd/elfnn-riscv.c:
> > > >
> > > > case R_RISCV_CALL_PLT:
> > > > /* This symbol requires a procedure linkage table entry. We
> > > > actually build the entry in adjust_dynamic_symbol,
> > > > because this might be a case of linking PIC code without
> > > > linking in any dynamic objects, in which case we don't
> > > > need to generate a procedure linkage table after all. */
> > > >
> > > > if (h != NULL)
> > > > {
> > > > h->needs_plt = 1;
> > > > h->plt.refcount += 1;
> > > > }
> > > > break;
> > > >
> > > > due to a reference from `addtf3.o', from `libgcc.a'. There are further 20
> > > > references for a total of 21. There is a later opportunity for the flag
> > > > to be cleared in `riscv_elf_adjust_dynamic_symbol', as observed in the
> > > > comment, however that only happens for symbols that bind locally, or which
> > > > are not referenced, and for `memset' obviously neither is the case (and
> > > > `allocate_dynrelocs' sets `h->plt.offset' in place of `h->plt.refcount'
> > > > then).
> > > >
> > > > I don't think we have a way to redirect the reference to `__GI_memset'.
> > >
> > > I'm not really clear where this ended up. I have a session at Plumbers
> > > next week to discuss the RV32 port and am planning on discussing this
> > > issue as well.
> >
> > This: <https://sourceware.org/pipermail/binutils/2020-August/112750.html>
> > ought to sort it AFAICT.
>
> Thanks!
>
> This was discussed in the RISC-V Plumbers session yesterday and the
> decision was made to just ignore this failure and wait for the
> binutils patch.
So apparently the binutils patch does not fix it.
I'm going to apply this patch. It has been acked by Palmer. Let me
know if anyone objects.
Alistair
>
> Alistair
>
> >
> > Maciej
^ permalink raw reply [flat|nested] 39+ messages in thread
end of thread, other threads:[~2020-09-12 22:02 UTC | newest]
Thread overview: 39+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-06-22 21:10 [PATCH] Allow memset local PLT reference for RISC-V Alistair Francis
2020-06-23 7:19 ` Andreas Schwab
2020-06-24 22:25 ` Alistair Francis
2020-06-25 7:20 ` Florian Weimer
2020-06-25 18:16 ` Vineet Gupta
2020-06-25 18:41 ` Florian Weimer
2020-06-26 3:58 ` Vineet Gupta
2020-06-29 9:11 ` Florian Weimer
2020-06-29 15:58 ` Alistair Francis
2020-06-29 16:00 ` Alistair Francis
2020-06-29 16:18 ` Florian Weimer
2020-06-29 16:11 ` Florian Weimer
2020-06-29 16:15 ` Alistair Francis
2020-06-29 16:30 ` Florian Weimer
2020-06-29 16:25 ` Alistair Francis
2020-06-29 16:39 ` Florian Weimer
2020-06-29 16:39 ` Alistair Francis
2020-06-29 16:53 ` Florian Weimer
2020-06-29 17:01 ` Andreas Schwab
2020-06-29 17:05 ` Florian Weimer
2020-06-29 17:44 ` Andreas Schwab
2020-06-30 0:26 ` Jim Wilson
2020-07-01 0:45 ` Maciej W. Rozycki
2020-07-10 21:35 ` Alistair Francis
2020-07-10 22:34 ` H.J. Lu
2020-07-12 1:32 ` Maciej W. Rozycki
2020-07-14 2:07 ` RISC-V: `ld.so' fails linking against `libgcc.a' built at `-O0' (was: Re: [PATCH] Allow memset local PLT reference for RISC-V.) Maciej W. Rozycki
2020-07-14 5:21 ` RISC-V: `ld.so' fails linking against `libgcc.a' built at `-O0' Andreas Schwab
2020-07-14 6:27 ` Richard Biener
2020-07-14 9:35 ` Maciej W. Rozycki
2020-08-20 22:39 ` [PATCH] Allow memset local PLT reference for RISC-V Alistair Francis
2020-08-21 10:44 ` Maciej W. Rozycki
2020-08-27 18:31 ` Alistair Francis
2020-09-12 21:51 ` Alistair Francis
2020-06-29 17:00 ` Andreas Schwab
2020-06-29 17:13 ` Florian Weimer
2020-06-29 17:46 ` Andreas Schwab
2020-06-25 0:20 ` Vineet Gupta
2020-06-25 21:27 ` Palmer Dabbelt
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).