On Sun, May 31, 2020 at 12:57:12AM +, Will Springer wrote:
> On Saturday, May 30, 2020 12:22:12 PM PDT Segher Boessenkool wrote:
> > The original sysv PowerPC supplement
> > http://refspecs.linux-foundation.org/elf/elfspec_ppc.pdf
> > supports LE as well, and mos
Hi!
On Fri, May 29, 2020 at 07:03:48PM +, Will Springer wrote:
> Hey all, a couple of us over in #talos-workstation on freenode have been
> working on an effort to bring up a Linux PowerPC userland that runs in 32-bit
> little-endian mode, aka ppcle. As far as we can tell, no ABI has ever
On Tue, May 19, 2020 at 10:22:40AM -0500, Paul A. Clarke wrote:
> On Tue, May 19, 2020 at 10:05:56AM -0500, Segher Boessenkool wrote:
> > On Tue, May 19, 2020 at 09:49:22AM -0500, Paul A. Clarke wrote:
> > > On Tue, May 19, 2020 at 10:31:56AM +1000, Alistair Popple wrote:
>
On Tue, May 19, 2020 at 09:49:22AM -0500, Paul A. Clarke wrote:
> On Tue, May 19, 2020 at 10:31:56AM +1000, Alistair Popple wrote:
> > Matrix multiple accumulate (MMA) is a new feature added to ISAv3.1 and
>
> nit: "Matrix-Multiply Accelerator".
"Matrix-Multiply Assist" in fact :-)
Segher
Hi!
On Mon, May 18, 2020 at 04:35:22PM +1000, Michael Ellerman wrote:
> Nicholas Piggin writes:
> > Provide an option to build big-endian kernels using the ELF V2 ABI. This
> > works
> > on GCC and clang (since about 2014). it is is not officially supported by
> > the
> > GNU toolchain, but it
"r" (msr & ~MSR_DR), "r" (msr));
That should be "="(val) (an earlyclobber), because when %0 is
written, %4 will still be used later.
Looks fine otherwise.
Reviewed-by: Segher Boessenkool
Segher
a ("powerpc/uaccess: Implement unsafe_put_user() using 'asm
> goto'")
> Signed-off-by: Michael Ellerman
Acked-by: Segher Boessenkool
Thanks! So much trouble for what looked like such a simple change, all
those years ago :-(
Segher
On Wed, May 06, 2020 at 08:10:57PM +0200, Christophe Leroy wrote:
> Le 06/05/2020 à 19:58, Segher Boessenkool a écrit :
> >> #define __put_user_asm_goto(x, addr, label, op) \
> >>asm volatile goto( \
> >>-
On Wed, May 06, 2020 at 11:36:00AM +1000, Michael Ellerman wrote:
> >> As far as I understood that's mandatory on recent gcc to get the
> >> pre-update form of the instruction. With older versions "m" was doing
> >> the same, but not anymore.
> >
> > Yes. How much that matters depends on the
On Wed, May 06, 2020 at 10:58:55AM +1000, Michael Ellerman wrote:
> >> The "m<>" here is breaking GCC 4.6.3, which we allegedly still support.
> >
> > [ You shouldn't use 4.6.3, there has been 4.6.4 since a while. And 4.6
> > is nine years old now. Most projects do not support < 4.8 anymore,
Hi!
On Thu, Apr 30, 2020 at 02:02:02PM +1000, Nicholas Piggin wrote:
> Add support for the scv instruction on POWER9 and later CPUs.
Looks good to me in general :-)
> For now this implements the zeroth scv vector 'scv 0', as identical
> to 'sc' system calls, with the exception that lr is not
Hi!
On Wed, Apr 29, 2020 at 12:39:22PM +1000, Nicholas Piggin wrote:
> Excerpts from Adhemerval Zanella's message of April 27, 2020 11:09 pm:
> >> Right, I'm just talking about those comments -- it seems like the kernel
> >> vdso should contain an .opd section with function descriptors in it for
On Tue, May 05, 2020 at 05:40:21PM +0200, Christophe Leroy wrote:
> >>+#define __put_user_asm_goto(x, addr, label, op)\
> >>+ asm volatile goto( \
> >>+ "1: " op "%U1%X1 %0,%1 # put_user\n" \
> >>+
Hi!
On Wed, May 06, 2020 at 12:27:58AM +1000, Michael Ellerman wrote:
> Christophe Leroy writes:
> > unsafe_put_user() is designed to take benefit of 'asm goto'.
> >
> > Instead of using the standard __put_user() approach and branch
> > based on the returned error, use 'asm goto' and make the
>
Hi!
On Tue, Apr 28, 2020 at 09:25:17PM +1000, Nicholas Piggin wrote:
> +config BUILD_BIG_ENDIAN_ELF_V2
> + bool "Build big-endian kernel using ELFv2 ABI (EXPERIMENTAL)"
> + depends on PPC64 && CPU_BIG_ENDIAN && EXPERT
> + default n
> + select BUILD_ELF_V2
> + help
> +
On Sat, Apr 25, 2020 at 08:53:13PM +0200, Borislav Petkov wrote:
> On Sat, Apr 25, 2020 at 01:37:01PM -0500, Segher Boessenkool wrote:
> > That is a lot more typing then
> > asm("");
>
> That's why a macro with a hopefully more descriptive name would be
> tel
On Sat, Apr 25, 2020 at 07:31:40PM +0200, Borislav Petkov wrote:
> > There's also the one in init/main.c which is used by multiple
> > architectures. On x86 at least, the call to arch_call_rest_init at the
> > end of start_kernel does not get tail-call optimized by gcc-10, but I
> > don't see
Hi,
On Tue, Apr 21, 2020 at 11:58:31AM +1000, Oliver O'Halloran wrote:
> On Tue, Apr 21, 2020 at 11:53 AM Alistair Popple
> wrote:
> >
> > On Tuesday, 21 April 2020 11:30:52 AM AEST Alistair Popple wrote:
> > > On Saturday, 4 April 2020 2:32:08 AM AEST Segher Bo
Hi!
On Tue, Apr 21, 2020 at 01:04:05AM +, Joel Stanley wrote:
> On Mon, 20 Apr 2020 at 18:38, Christophe Leroy
> wrote:
> > _ALIGN_DOWN() is specific to powerpc
> > ALIGN_DOWN() is generic and does the same
> >
> > Replace _ALIGN_DOWN() by ALIGN_DOWN()
>
> This one is a bit less obvious.
Hi!
On Sat, Apr 18, 2020 at 08:28:53AM +, Christophe Leroy wrote:
> I'd like to use cr instead of gpr to return error condition from
> __get_user().
>
> I saw in GCC doc
> (https://gcc.gnu.org/onlinedocs/gcc/Machine-Constraints.html) that it is
> possible to use "y" as constraint to refer
On Thu, Apr 16, 2020 at 08:34:42PM -0400, Rich Felker wrote:
> On Thu, Apr 16, 2020 at 06:02:35PM -0500, Segher Boessenkool wrote:
> > On Thu, Apr 16, 2020 at 08:12:19PM +0200, Florian Weimer wrote:
> > > > I think my choice would be just making the inline syscall be a sin
Hi!
On Thu, Apr 16, 2020 at 07:50:00AM +0200, Christophe Leroy wrote:
> Le 16/04/2020 à 00:06, Segher Boessenkool a écrit :
> >On Wed, Apr 15, 2020 at 09:20:26AM +, Christophe Leroy wrote:
> >>At the time being, __put_user()/__get_user() and friends only use
>
On Thu, Apr 16, 2020 at 08:12:19PM +0200, Florian Weimer wrote:
> > I think my choice would be just making the inline syscall be a single
> > call insn to an asm source file that out-of-lines the loading of TOC
> > pointer and call through it or branch based on hwcap so that it's not
> > repeated
On Thu, Apr 16, 2020 at 02:41:56PM +0200, Christophe Leroy wrote:
> Le 16/04/2020 à 00:37, Segher Boessenkool a écrit :
> >>+ __put_user_nocheck_goto((__typeof__(*(ptr)))(x), (ptr),
> >>sizeof(*(ptr)), label)
> >
> >This line gets too long, can you break it
"2: stw%U1%X1 %L0, %L1\n" \
> + EX_TABLE(1b, %l2) \
> + EX_TABLE(2b, %l2) \
> + : \
> + : "r" (x), "m" (*addr) \
> + : \
> + : label)
> +#endif /* __powerpc64__ */
Here, you should drop it for sure.
Rest looks fine.
Reviewed-by: Segher Boessenkool
Segher
ot;=r" (err) \
> - : "r" (x), "b" (addr), "i" (-EFAULT), "0" (err))
> + : "r" (x), "m" (*addr), "i" (-EFAULT), "0" (err))
Here, it doesn't work. You don't want two consecutive update insns in
any case. Easiest is to just not use "m<>", and then, don't use %Un
(which won't do anything, but it is confusing).
Same for the reads.
Rest looks fine, and update should be good with that fixed as said.
Reviewed-by: Segher Boessenkool
Segher
Hi!
On Mon, Apr 06, 2020 at 06:09:20PM +1000, Jordan Niethe wrote:
> +static inline int ppc_inst_opcode(u32 x)
> +{
> + return x >> 26;
> +}
Maybe you should have "primary opcode" in this function name?
Segher
On Mon, Apr 06, 2020 at 12:25:27PM +0200, Christophe Leroy wrote:
> > if (ppc_inst_prefixed(x) != ppc_inst_prefixed(y))
> > return false;
> > else if (ppc_inst_prefixed(x))
> > return !memcmp(, , sizeof(struct ppc_inst));
>
> Are we sure memcmp() is a good
Hi!
On Fri, Apr 03, 2020 at 03:10:54PM +1100, Alistair Popple wrote:
> +#define PCR_ARCH_300 0x10/* Architecture 3.00 */
It's called 3.0, not 3.00?
Segher
On Tue, Mar 31, 2020 at 08:56:23AM +0200, Christophe Leroy wrote:
> While we are at it, can we also remove the 601 ? This one is also full
> of workarounds and diverges a bit from other 6xx.
>
> I'm unable to find its end of life date, but it was on the market in
> 1994, so I guess it must be
On Fri, Mar 27, 2020 at 09:50:54AM -0700, Fangrui Song wrote:
> We aim for compatibility with GNU in many aspects to make it easier for
> people to switch over. However, just because there is a subtle behavior
> in GNU toolchain does not mean we need to emulate that behavior.
It isn't subtle. It
On Fri, Mar 27, 2020 at 04:12:13PM +0100, Christophe Leroy wrote:
> Maybe you could also change invalidate_dcache_range():
>
> for (i = 0; i < size >> shift; i++, addr += bytes) {
> if (IS_ENABLED(CONFIG_PPC_BOOK3S_64))
> dcbf(addr);
> else
Hi!
On Thu, Mar 26, 2020 at 01:38:39PM +0100, Clement Courbet wrote:
> --- a/arch/powerpc/include/asm/setjmp.h
> +++ b/arch/powerpc/include/asm/setjmp.h
> @@ -12,7 +12,9 @@
>
> #define JMP_BUF_LEN23
> -extern long setjmp(long *);
> -extern void longjmp(long *, long);
> +typedef long *
On Thu, Mar 26, 2020 at 03:26:12PM -0700, Fangrui Song wrote:
> On 2020-03-26, Segher Boessenkool wrote:
> >On Wed, Mar 25, 2020 at 09:42:57AM -0700, Fangrui Song wrote:
> >>.globl sets the symbol binding to STB_GLOBAL while .weak sets the
> >>binding to STB_WEAK. GNU a
On Wed, Mar 25, 2020 at 09:42:57AM -0700, Fangrui Song wrote:
> .globl sets the symbol binding to STB_GLOBAL while .weak sets the
> binding to STB_WEAK. GNU as let .weak override .globl since binutils-gdb
> 5ca547dc2399a0a5d9f20626d4bf5547c3ccfddd (1996). Clang integrated
> assembler let the last
On Tue, Mar 24, 2020 at 10:18:20PM -0700, Fangrui Song wrote:
> .globl sets the symbol binding to STB_GLOBAL while .weak sets the
> binding to STB_WEAK. They should not be used together. It is accidetal
> rather then intentional that GNU as let .weak override .globl while
> clang integrated
On Mon, Mar 23, 2020 at 04:55:48PM +0530, Balamuruhan S wrote:
> Data Cache Block Invalidate (dcbi) instruction implemented in 32-bit
> designs prior to PowerPC architecture version 2.01 and got obsolete
> from version 2.01.
It was added back in 2.03. It also exists in 64-bit designs (using
On Fri, Mar 20, 2020 at 08:38:42PM +0530, Aneesh Kumar K.V wrote:
> On 3/20/20 8:35 PM, Segher Boessenkool wrote:
> >On Fri, Mar 20, 2020 at 04:02:42PM +0530, Aneesh Kumar K.V wrote:
> >>As per ISA and isync is only needed on instruction cache
> >>block invalidate.
On Fri, Mar 20, 2020 at 04:02:42PM +0530, Aneesh Kumar K.V wrote:
> As per ISA and isync is only needed on instruction cache
> block invalidate. Remove the same from dcache invalidate.
Is that true on older CPUs?
Segher
On Wed, Mar 18, 2020 at 12:44:52PM +0100, Christophe Leroy wrote:
> Le 18/03/2020 à 12:35, Michael Ellerman a écrit :
> >Christophe Leroy writes:
> >>Le 09/03/2020 à 09:58, Ravi Bangoria a écrit :
> >>>Currently we assume that we have only one watchpoint supported by hw.
> >>>Get rid of that
On Tue, Mar 17, 2020 at 11:16:34AM +0100, Christophe Leroy wrote:
>
>
> Le 09/03/2020 à 09:57, Ravi Bangoria a écrit :
> >Future Power architecture is introducing second DAWR. Add SPRN_ macros
> >for the same.
>
> I'm not sure this is called 'macros'. For me a macro is something more
>
On Mon, Mar 16, 2020 at 04:05:01PM +0100, Christophe Leroy wrote:
> Some book3s (e300 family for instance, I think G2 as well) already have
> a DABR2 in addition to DABR.
The original "G2" (meaning 603 and 604) do not have DABR2. The newer
"G2" (meaning e300) does have it. e500 and e600 do not
On Fri, Mar 13, 2020 at 01:49:07PM -0400, Athira Rajeev wrote:
> Sampled instruction address register (SIER), is a PMU register,
SIER stands for "Sampled Instruction Event Register", instead. With that
change, your patch is totally clear :-)
Segher
On Sat, Mar 07, 2020 at 10:58:54AM +1000, Nicholas Piggin wrote:
> Segher Boessenkool's on March 5, 2020 8:55 pm:
> > That name looks perfect to me. You'll have to update REs expecting the
> > arch at the end (like /le$/), but you had to already I think?
>
> le$ is still okay for testing
all in assembly.
That may change, but it is easy to change again for just the VDSOs.
> Reported-by: Rasmus Villemoes
> Signed-off-by: Naveen N. Rao
Reviewed-by: Segher Boessenkool
Thanks!
Segher
On Thu, Mar 05, 2020 at 01:34:22PM +1000, Nicholas Piggin wrote:
> Segher Boessenkool's on March 4, 2020 9:09 am:
> >> +override flavour := linux-ppc64v2
> >
> > That isn't a good name, heh. This isn't "v2" of anything... Spell out
> > the name "ELFv2"? Or as "elfv2"? It is just a name after
after all, it is
version 1 in all three version fields in the ELF headers!
Anyway, looks like it will work, let's see where this goes :-)
Reviewed-by: Segher Boessenkool
Segher
On Mon, Mar 02, 2020 at 11:56:05AM +0100, Rasmus Villemoes wrote:
> I'm building a ppc32 kernel, and noticed that after upgrading from gcc-7
> to gcc-8 all object files now end up having .eh_frame section.
Since GCC 8, we enable -fasynchronous-unwind-tables by default for
PowerPC. See
On Mon, Mar 02, 2020 at 09:51:44PM +1100, Michael Ellerman wrote:
> Linus Torvalds writes:
> > Michael, what tends to be the triggers for people using
> > PPC_DISABLE_WERROR? Do you have reports for it?
>
> My memory is that we have had very few reports of it actually causing
> problems. But I
Hi!
On Wed, Feb 26, 2020 at 03:35:35AM +1000, Nicholas Piggin wrote:
> Kernel addresses and potentially other sensitive data could be leaked
> in volatile registers after a syscall.
> cmpdi r3,0
> bne .Lsyscall_restore_regs
> + li r0,0
> + li r4,0
> + li
On Mon, Feb 24, 2020 at 01:32:28PM +1100, Alexey Kardashevskiy wrote:
> On 17/02/2020 13:48, Oliver O'Halloran wrote:
> > Treat an empty reboot cmd string the same as a NULL string. This squashes a
> > spurious unsupported reboot message that sometimes gets out when using
> > xmon.
> > -
On Mon, Feb 17, 2020 at 11:08:52AM -0500, Joe Lawrence wrote:
> I was wondering if there was history behind VDS64_HAS_DESCRIPTORS and in
> what cases would one want to turn them on? (Note, I'm assuming they are
> an implementation of Function Descriptors. [1])
It's from the very first patch
On Wed, Feb 19, 2020 at 10:52:16AM +0100, Arnd Bergmann wrote:
> On Wed, Feb 19, 2020 at 9:45 AM Christophe Leroy
> wrote:
> > Le 16/02/2020 à 19:10, Arnd Bergmann a écrit :
> > > On Sat, Jan 11, 2020 at 12:33 PM Segher Boessenkool
> > > wrote:
> > >>
On Mon, Feb 17, 2020 at 05:23:07PM +1100, Michael Neuling wrote:
> > > Hence, we should NOP this, not generate an illegal.
> >
> > It is not a reserved bit.
> >
> > The IMC entry for it matches op1=01 op2=101110 presumably, which
> > catches all TM instructions and nothing else (bits
On Mon, Feb 17, 2020 at 12:07:31PM +1100, Michael Neuling wrote:
> On Thu, 2020-02-13 at 10:15 -0500, Gustavo Romero wrote:
> > On P9 DD2.2 due to a CPU defect some TM instructions need to be emulated by
> > KVM. This is handled at first by the hardware raising a softpatch interrupt
> > when
of the case above by treating the
> unrecognized TM instructions that can raise a softpatch but are not
> defined in the ISA as illegal ones instead of as 'nop' and by gently
> reporting it to the host instead of throwing a trace.
>
> Signed-off-by: Gustavo Romero
Reviewed-by: Seg
On Tue, Feb 04, 2020 at 02:38:51PM +0100, David Hildenbrand wrote:
> On 04.02.20 14:13, Segher Boessenkool wrote:
> > On Tue, Feb 04, 2020 at 01:41:06PM +0100, David Hildenbrand wrote:
> >> It's a pattern commonly used in compilers and emulators to calculate the
> >>
On Tue, Feb 04, 2020 at 01:41:06PM +0100, David Hildenbrand wrote:
> On 04.02.20 10:46, Oscar Salvador wrote:
> > I have to confess that it took me while to wrap around my head
> > with the new min() change, but looks ok:
>
> It's a pattern commonly used in compilers and emulators to calculate
On Mon, Feb 03, 2020 at 07:21:52AM +0100, Christophe Leroy wrote:
> Le 03/02/2020 à 02:00, Patchwork a écrit :
> >The following patch (submitted by you) has been updated in Patchwork:
> >
> > * linuxppc-dev: powerpc/nohash: Don't flush all TLBs when flushing one
> > page
> > -
UND_DOWN and ROUND_UP macros you could use?
>
> Yes but my intention was to modify the existing code as less as possible.
> What do you think about version v2 of the patch ?
It looked fine to me.
Add my
Reviewed-by: Segher Boessenkool
if you want.
Segher
On Sat, Feb 01, 2020 at 08:27:03AM +0100, Christophe Leroy wrote:
> Le 31/01/2020 à 20:38, Segher Boessenkool a écrit :
> >On Fri, Jan 31, 2020 at 05:15:20PM +0100, Christophe Leroy wrote:
> >>Le 31/01/2020 à 16:51, Segher Boessenkool a écrit :
> >>>On Fri, Ja
On Fri, Jan 31, 2020 at 05:15:20PM +0100, Christophe Leroy wrote:
> Le 31/01/2020 à 16:51, Segher Boessenkool a écrit :
> >On Fri, Jan 31, 2020 at 03:37:34PM +, Christophe Leroy wrote:
> >>When the range is a single page, do a page flush instead.
> >
> >>+
On Fri, Jan 31, 2020 at 03:37:34PM +, Christophe Leroy wrote:
> When the range is a single page, do a page flush instead.
> + start &= PAGE_MASK;
> + end = (end - 1) | ~PAGE_MASK;
> if (!Hash) {
> - _tlbia();
> + if (end - start == PAGE_SIZE)
> +
Hi!
On Fri, Jan 31, 2020 at 08:30:45AM -0300, Adhemerval Zanella wrote:
> On 30/01/2020 18:41, Segher Boessenkool wrote:
> > On Thu, Jan 30, 2020 at 02:04:51PM -0300, Adhemerval Zanella wrote:
> >> be value propagated over
> >> functions calls and over different sco
Hi!
On Thu, Jan 30, 2020 at 02:04:51PM -0300, Adhemerval Zanella wrote:
> On 30/01/2020 10:50, Segher Boessenkool wrote:
> > On Thu, Jan 30, 2020 at 01:03:53PM +0100, Florian Weimer wrote:
> >>> This is why that *is* the only supported use. The documentation could
> >
Hi again,
On Thu, Jan 30, 2020 at 01:03:53PM +0100, Florian Weimer wrote:
> > This is why that *is* the only supported use. The documentation could
> > use a touch-up, I think. Unless we still have problems here?
>
> I really don't know. GCC still has *some* support for the old behavior,
>
On Thu, Jan 30, 2020 at 11:42:51AM +0100, Florian Weimer wrote:
> * Segher Boessenkool:
> > No, that *is* supported: as input to or output from an asm, a local
> > register asm variable *is* guaranteed to live in the specified register.
> > This is the *only* supported
On Wed, Jan 29, 2020 at 06:02:34PM +0100, Florian Weimer wrote:
> * Segher Boessenkool:
>
> > On Wed, Jan 29, 2020 at 05:19:19PM +0100, Florian Weimer wrote:
> >> * Segher Boessenkool:
> >> >> But GCC doesn't expose them as integers to C code, so yo
On Wed, Jan 29, 2020 at 05:19:19PM +0100, Florian Weimer wrote:
> * Segher Boessenkool:
> >> But GCC doesn't expose them as integers to C code, so you can't do much
> >> without them.
> >
> > Sure, it doesn't expose any other registers directly, either.
>
On Wed, Jan 29, 2020 at 02:58:44PM +1000, Nicholas Piggin wrote:
> Adhemerval Zanella's on January 29, 2020 3:26 am:
> > __asm__ __volatile__\
> > ("sc\n\t" \
> >"bns+ 1f\n\t"
On Tue, Jan 28, 2020 at 05:04:49PM +0100, Florian Weimer wrote:
> * Segher Boessenkool:
>
> >> > I don't think we can save LR in a regular register around the system
> >> > call, explicitly in the inline asm statement, because we still have to
> >> > g
On Wed, Jan 29, 2020 at 12:05:40AM +1000, Nicholas Piggin wrote:
> Florian Weimer's on January 28, 2020 11:09 pm:
> > But I don't think we are so lucky for the inline system calls. GCC
> > recognizes an "lr" clobber with inline asm (even though it is not
> > documented), but it generates rather
On Fri, Jan 24, 2020 at 07:03:36AM +, Christophe Leroy wrote:
> >Le 24/01/2020 à 06:46, Michael Ellerman a écrit :
> >>
> >>If I do this it seems to work, but feels a little dicey:
> >>
> >>asm ("" : "=r" (r1));
> >>sp = r1 & (THREAD_SIZE - 1);
> >
> >
> >Or we could do add in
Hi!
On Fri, Jan 24, 2020 at 04:46:24PM +1100, Michael Ellerman wrote:
> Christophe Leroy writes:
> > static inline void check_stack_overflow(void)
> > {
> > #ifdef CONFIG_DEBUG_STACKOVERFLOW
> > - long sp;
> > -
> > - sp = current_stack_pointer() & (THREAD_SIZE-1);
> > + register
On Wed, Jan 22, 2020 at 07:52:02AM +0100, Christophe Leroy wrote:
> Le 21/01/2020 à 20:55, Segher Boessenkool a écrit :
> >On Tue, Jan 21, 2020 at 05:22:32PM +, Christophe Leroy wrote:
> >>g1() should return 3, not 5.
> >
> >What makes you say that?
>
>
Hi!
On Wed, Jan 22, 2020 at 07:57:15AM +0100, Christophe Leroy wrote:
> GCC doc also says:
>
> "if you use it in an inlined function and pass an argument of the
> function as the argument to the built-in, GCC never returns 1 when you
> call the inline function with a string constant"
>
> Does
On Tue, Jan 21, 2020 at 05:22:32PM +, Christophe Leroy wrote:
> g1() should return 3, not 5.
What makes you say that?
"A return of 0 does not indicate that the
value is _not_ a constant, but merely that GCC cannot prove it is a
constant with the specified value of the '-O' option."
(And
On Mon, Jan 20, 2020 at 05:52:15PM -0800, Joe Perches wrote:
> On Tue, 2020-01-21 at 09:31 +0800, Chen Zhou wrote:
> > Fixes coccicheck warning:
> > ./arch/powerpc/platforms/maple/setup.c:232:15-16:
> > WARNING comparing pointer to 0
>
> Does anyone have or use these powerpc maple boards
On Mon, Jan 20, 2020 at 06:08:23PM +0100, Christophe Leroy wrote:
> Not easy I think.
>
> First we have the unavoidable ASM entry function that can't be dropped
> because of the CR[SO] bit the set on error or clear on no error and that
> can't be done in C.
Yup.
> In our ASM VDSO, fixed
On Mon, Jan 20, 2020 at 02:56:00PM +, Christophe Leroy wrote:
> >Nice! Much better.
> >
> >It should be tested on more representative hardware, too, but this looks
> >promising alright :-)
>
> mpc832x (e300c2 core) at 333 MHz:
>
> Before:
>
> gettimeofday:vdso: 235 nsec/call
>
Hi!
On Thu, Jan 16, 2020 at 05:58:24PM +, Christophe Leroy wrote:
> On a powerpc8xx, with current powerpc/32 ASM VDSO:
>
> gettimeofday:vdso: 907 nsec/call
> clock-getres-realtime:vdso: 484 nsec/call
> clock-gettime-realtime:vdso: 899 nsec/call
>
> The first patch adds VDSO
Hi!
On Thu, Jan 16, 2020 at 03:54:58PM +, David Laight wrote:
> if you are trying to 'loop carry' the 'carry flag' with 'add with carry'
> instructions you'll almost certainly need to write the loop in asm.
> Since the loop itself is simple, this probably doesn't matter.
Agreed.
> However a
Hi!
On Thu, Jan 16, 2020 at 07:11:36AM +0100, Christophe Leroy wrote:
> I'm trying to see if we could enhance TCP checksum calculations by
> splitting inline assembly blocks to give GCC the opportunity to mix it
> with other stuff, but I'm getting difficulties with the carry.
>
> As far as I
On Thu, Jan 16, 2020 at 09:06:08AM +0100, Gabriel Paubert wrote:
> On Thu, Jan 16, 2020 at 07:11:36AM +0100, Christophe Leroy wrote:
> > Hi Segher,
> >
> > I'm trying to see if we could enhance TCP checksum calculations by splitting
> > inline assembly blocks to give GCC the opportunity to mix it
On Tue, Jan 14, 2020 at 05:53:41AM -0600, Timur Tabi wrote:
> On 1/14/20 2:29 AM, Segher Boessenkool wrote:
> >You have no working lswx I suppose?:-)
>
> I don't know if the P4080 supports lswx, but it does, than that would be
> an elegant way to fix this bug.
No e500 version
On Mon, Jan 13, 2020 at 07:10:11PM -0600, Timur Tabi wrote:
> Ah, I see now. This is all coming back to me.
>
> I would prefer that ev_byte_channel_send() is updated to access only
> 'count' bytes. If that means adding a memcpy to the
> ev_byte_channel_send() itself, then so be it. Trying to
On Fri, Jan 10, 2020 at 07:45:44AM +0100, Christophe Leroy wrote:
> Le 09/01/2020 à 21:07, Segher Boessenkool a écrit :
> >It looks like the compiler did loop peeling. What GCC version is this?
> >Please try current trunk (to become GCC 10), or at least GCC 9?
>
> It is wi
On Thu, Jan 09, 2020 at 05:52:34PM +, Christophe Leroy wrote:
> Wondering why we get something so complicated/redundant for
> vdso_read_begin()
>
> static __always_inline u32 vdso_read_begin(const struct vdso_data *vd)
> {
> u32 seq;
>
> while ((seq = READ_ONCE(vd->seq)) & 1)
>
On Tue, Dec 24, 2019 at 08:15:11PM +0800, Andy Lutomirski wrote:
> Does power have PC-relative data access? If so, I wonder if the code can be
> arranged so that even the array accesses don’t require computing an absolute
> address at any point.
Not before ISA 3.0 (that is Power9).
The
Hi!
On Fri, Dec 13, 2019 at 11:07:55PM +1100, Michael Ellerman wrote:
> I tried this:
>
> > @@ -295,6 +296,23 @@ void __write_once_size(volatile void *p, void *res,
> > int size)
> > */
> > #define READ_ONCE_NOCHECK(x) __READ_ONCE(x, 0)
> >
> > +#else /* GCC_VERSION < 40800 */
> > +
> >
On Thu, Dec 12, 2019 at 09:41:32AM -0800, Linus Torvalds wrote:
> Yeah, I know, but this really wants a comment. Sadly it looks like gcc
> bugzilla is down, so
>
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58145
>
> currently gives an "Internal Server Error" for me.
We're being DoSsed
Hi,
On Thu, Dec 12, 2019 at 04:42:13PM +1100, Michael Ellerman wrote:
> Some of the generic versions don't generate good code compared to our
> versions, but that's because READ_ONCE() is triggering stack protector
> to be enabled.
The *big* difference is the generic code has a special path that
Hi!
On Mon, Dec 09, 2019 at 06:37:09AM +0100, Christophe Leroy wrote:
> What do you mean by NX ?
It is the Power9 "Nest Accelerator". The patch series should ideally
mention that right at the start, yeah.
> Up to now, NX has been standing for No-eXecute. That's a bit in segment
> registers on
On Sat, Dec 07, 2019 at 10:42:28AM +0100, Christophe Leroy wrote:
> Le 06/12/2019 à 21:59, Segher Boessenkool a écrit :
> >If the compiler can see the callee wants the same TOC as the caller has,
> >it does not arrange to set (and restore) it, no. If it sees it may be
> &
Hi,
On Thu, Dec 05, 2019 at 07:37:24PM -0600, Frank Rowand wrote:
> On 12/3/19 12:35 PM, Segher Boessenkool wrote:
> > Btw. Some OFs mangle the phandles some way, to make it easier to catch
> > people using it as an address (and similarly, mangle ihandles differently,
> > s
On Wed, Dec 04, 2019 at 05:32:54AM +0100, Christophe Leroy wrote:
> Le 29/11/2019 à 19:46, Segher Boessenkool a écrit :
> >The existing call_do_irq isn't C code. It doesn't do anything with r2,
> >as far as I can see; __do_irq just gets whatever the caller of call_do_irq
> >h
Hi!
On Tue, Dec 03, 2019 at 03:03:22PM +1100, Michael Ellerman wrote:
> Sebastian Andrzej Siewior writes:
> I've certainly heard it said that on some OF's the phandle was just ==
> the address of the internal representation, and I guess maybe for SLOF
> that is true.
It is (or was). In many
Hi!
On Wed, Nov 27, 2019 at 04:15:15PM +0100, Christophe Leroy wrote:
> Le 27/11/2019 à 15:59, Segher Boessenkool a écrit :
> >On Wed, Nov 27, 2019 at 02:50:30PM +0100, Christophe Leroy wrote:
> >>So what do we do ? We just drop the "r2" clobber ?
> >
> >Y
On Wed, Nov 27, 2019 at 02:50:30PM +0100, Christophe Leroy wrote:
> So what do we do ? We just drop the "r2" clobber ?
You have to make sure your asm code works for all ABIs. This is quite
involved if you do a call to an external function. The compiler does
*not* see this call, so you will have
On Mon, Nov 25, 2019 at 09:32:23PM +1100, Michael Ellerman wrote:
> Segher Boessenkool writes:
> >> > +static inline void call_do_irq(struct pt_regs *regs, void *sp)
> >> > +{
> >> > +register unsigned long r3 asm("r3") = (unsigned long)reg
401 - 500 of 1471 matches
Mail list logo
