Re: __syscall_error (was Re: [PATCH v4 13/15] ARC: Build Infrastructure)
On 4/2/20 1:50 AM, Florian Weimer via Libc-alpha wrote: >> What if you move it to GLIBC_PRIVATE? My concern isn't that it's exported >> from the shared library, it's that it's exported at a public version. > > I think it's preferable to duplicate __syscall_error in each shared > object that needs it. It avoids potential strange loops if the lazy > binding code itself ends up calling __syscall_error in an different > object (e.g., from the DSO that implements malloc). > > Maybe we can make this work as long as libc.so uses an internal call, > but it looks tricky. > > Alternatively, we can enable BIND_NOW unconditionally. This seems too big of a trade-off for a seeming small optimization. If you folks feel strongly, I can drop all of this __syscall_error dance. Just let me know what approach to take. ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH] ARC: Fix ICCM & DCCM runtime size checks
As of today the ICCM and DCCM size checks are incorrectly using
mismatched units (KiB checked against bytes). The CONFIG_ARC_DCCM_SZ
and CONFIG_ARC_ICCM_SZ are in KiB, but the size calculated in
runtime and stored in cpu->dccm.sz and cpu->iccm.sz is in bytes.
Fix that.
Reported-by: Paul Greco
Signed-off-by: Eugeniy Paltsev
---
arch/arc/kernel/setup.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/arc/kernel/setup.c b/arch/arc/kernel/setup.c
index aa41af6ef4ac..efdedf83b954 100644
--- a/arch/arc/kernel/setup.c
+++ b/arch/arc/kernel/setup.c
@@ -11,6 +11,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -409,12 +410,12 @@ static void arc_chk_core_config(void)
if ((unsigned int)__arc_dccm_base != cpu->dccm.base_addr)
panic("Linux built with incorrect DCCM Base address\n");
- if (CONFIG_ARC_DCCM_SZ != cpu->dccm.sz)
+ if (CONFIG_ARC_DCCM_SZ * SZ_1K != cpu->dccm.sz)
panic("Linux built with incorrect DCCM Size\n");
#endif
#ifdef CONFIG_ARC_HAS_ICCM
- if (CONFIG_ARC_ICCM_SZ != cpu->iccm.sz)
+ if (CONFIG_ARC_ICCM_SZ * SZ_1K != cpu->iccm.sz)
panic("Linux built with incorrect ICCM Size\n");
#endif
--
2.21.1
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [RFC] ARC: initial ftrace support
On Thu, 2 Apr 2020 01:17:01 +
Vineet Gupta wrote:
> +CC Claudiu
>
> On 3/27/20 10:10 AM, Steven Rostedt wrote:
> > On Fri, 27 Mar 2020 18:53:55 +0300
> > Eugeniy Paltsev wrote:
>
> Maybe add a comment that gcc does the heavy lifting: I have following in glibc
>
> +/* this is very simple as gcc does all the heavy lifting at _mcount call site
> + * - sets up caller's blink in r0, so frompc is setup correctly
> + * - preserve argument registers for original call */
>
> >> +noinline void _mcount(unsigned long parent_ip)
> >> +{
> >> + unsigned long ip = (unsigned long)__builtin_return_address(0);
> >> +
> >> + if (unlikely(ftrace_trace_function != ftrace_stub))
> >> + ftrace_trace_function(ip - MCOUNT_INSN_SIZE, parent_ip,
> >> +NULL, NULL);
> >> +}
> >> +EXPORT_SYMBOL(_mcount);
> >
> > So, ARCv2 allows the _mcount code to be written in C? Nice!
>
> Yeah, the gcc backend for -pg was overhauled recently so it is a first class
> "lib
> call" meaning we get all the register save/restore for free as well as caller
> PC
> (blink) as explicit argument to _mcount
>
> void bar(int a, int b, int c) {
> printf("%d\n", a, b, c);
> }
>
> bar:
> push_s blink
> std.a r14,[sp,-8]
> push_s r13
> mov_s r14,r1
> mov_s r13,r0
> mov_s r0,blink
> bl.d @_mcount
> mov_s r15,r2
>
> mov_s r3,r15 <-- restore args for call
We really don't want this. :-/
This will make it really difficult to implement the dynamic ftrace, and
this causes more overhead when tracing is not enabled.
Also, ftrace is much more complex, and this will make it difficult to have
function graph tracing and other features.
Gcc has an "instrument-functions" which people asked me why I didn't go
that route, as it lets you do the same (call C code), and its because of
the overhead it adds to each function that I turned it down.
-- Steve
> mov_s r2,r14
> mov_s r1,r13
> mov_s r0,@.LC0
> ld blink,[sp,12]
> pop_s r13
> b.d @printf
> ldd.ab r14,[sp,12]
>
> @Eugeniy, this patch looks ok to me, but a word of caution. This won't work
> with
> elf32 toolchain which some of the build systems tend to use (Alexey ?)
>
> The above _mcount semantics is only implemented for the linux tool-chains.
> elf32-gcc generates "legacy" __mcount (2 underscores, blink not provided as
> arg)
> likely done by Claudiu to keep newlib stuff unchanged. Perhaps elf32 gcc can
> add a
> toggle to get new _mcount.
>
> And this is conditional to ARCv2 due to future ties into dynamic ftrace and
> instruction fudging etc ? We may have to revisit that for BE anyhow given
> such a
> customer lining up.
>
> -Vineet
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
RE: [RFC] ARC: initial ftrace support
Hi Claus, > -Original Message- > From: linux-snps-arc On Behalf > Of Claudiu Zissulescu > Ianculescu > Sent: Thursday, April 2, 2020 11:10 AM > To: Vineet Gupta > Cc: Alexey Brodkin ; linux-ker...@vger.kernel.org; > Steven Rostedt > ; Ingo Molnar ; > linux-snps-arc@lists.infradead.org; Eugeniy > Paltsev > Subject: Re: [RFC] ARC: initial ftrace support > > Hi, > > ARC-gcc has two modes to call the mcount routines. When using elf32 > configuration, the toolchain is set to use newlib mcount. When > configured for linux, gcc toolchain is using a library call to _mcall > (single underscore) having blink as input argument. > So, using the proper linux toolchain, your patch should work. Is there a chance to switch to Linux-style mcount in Elf32 toolchain with a command-line option? Otherwise I guess we'll need to implement some warning which explicitly says why Elf32 toolchain is not usable for building the Linux kernel... at least in case with ftrace enabled. -Alexey ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: __syscall_error (was Re: [PATCH v4 13/15] ARC: Build Infrastructure)
* Joseph Myers: > What if you move it to GLIBC_PRIVATE? My concern isn't that it's exported > from the shared library, it's that it's exported at a public version. I think it's preferable to duplicate __syscall_error in each shared object that needs it. It avoids potential strange loops if the lazy binding code itself ends up calling __syscall_error in an different object (e.g., from the DSO that implements malloc). Maybe we can make this work as long as libc.so uses an internal call, but it looks tricky. Alternatively, we can enable BIND_NOW unconditionally. Thanks, Florian ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [RFC] ARC: initial ftrace support
Hi,
ARC-gcc has two modes to call the mcount routines. When using elf32
configuration, the toolchain is set to use newlib mcount. When
configured for linux, gcc toolchain is using a library call to _mcall
(single underscore) having blink as input argument.
So, using the proper linux toolchain, your patch should work.
//C
On Thu, Apr 2, 2020 at 4:17 AM Vineet Gupta wrote:
>
> +CC Claudiu
>
> On 3/27/20 10:10 AM, Steven Rostedt wrote:
> > On Fri, 27 Mar 2020 18:53:55 +0300
> > Eugeniy Paltsev wrote:
>
> Maybe add a comment that gcc does the heavy lifting: I have following in glibc
>
> +/* this is very simple as gcc does all the heavy lifting at _mcount call site
> + * - sets up caller's blink in r0, so frompc is setup correctly
> + * - preserve argument registers for original call */
>
> >> +noinline void _mcount(unsigned long parent_ip)
> >> +{
> >> +unsigned long ip = (unsigned long)__builtin_return_address(0);
> >> +
> >> +if (unlikely(ftrace_trace_function != ftrace_stub))
> >> +ftrace_trace_function(ip - MCOUNT_INSN_SIZE, parent_ip,
> >> + NULL, NULL);
> >> +}
> >> +EXPORT_SYMBOL(_mcount);
> >
> > So, ARCv2 allows the _mcount code to be written in C? Nice!
>
> Yeah, the gcc backend for -pg was overhauled recently so it is a first class
> "lib
> call" meaning we get all the register save/restore for free as well as caller
> PC
> (blink) as explicit argument to _mcount
>
> void bar(int a, int b, int c) {
> printf("%d\n", a, b, c);
> }
>
> bar:
> push_s blink
> std.a r14,[sp,-8]
> push_s r13
> mov_s r14,r1
> mov_s r13,r0
> mov_s r0,blink
> bl.d @_mcount
> mov_s r15,r2
>
> mov_s r3,r15 <-- restore args for call
> mov_s r2,r14
> mov_s r1,r13
> mov_s r0,@.LC0
> ld blink,[sp,12]
> pop_s r13
> b.d @printf
> ldd.ab r14,[sp,12]
>
> @Eugeniy, this patch looks ok to me, but a word of caution. This won't work
> with
> elf32 toolchain which some of the build systems tend to use (Alexey ?)
>
> The above _mcount semantics is only implemented for the linux tool-chains.
> elf32-gcc generates "legacy" __mcount (2 underscores, blink not provided as
> arg)
> likely done by Claudiu to keep newlib stuff unchanged. Perhaps elf32 gcc can
> add a
> toggle to get new _mcount.
>
> And this is conditional to ARCv2 due to future ties into dynamic ftrace and
> instruction fudging etc ? We may have to revisit that for BE anyhow given
> such a
> customer lining up.
>
> -Vineet
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
