RE: [PATCH] MIPS: VDSO: Always select -msoft-float

2016-11-04 Thread Matthew Fortune
Maciej Rozycki writes: > On Fri, 4 Nov 2016, Guenter Roeck wrote: > > > > As above, unless absolutely critical to have floating point code > > > then the vDSO should just avoid all FP related issues and build > soft-float. ... > > Anyway, isn't the kernel supposed to not use floating point operat

RE: [PATCH] MIPS: VDSO: Always select -msoft-float

2016-11-04 Thread Matthew Fortune
Maciej Rozycki writes: > On Tue, 1 Nov 2016, Guenter Roeck wrote: > > > > > Some toolchains fail to build mips images with the following build > error. > > > > > > > > arch/mips/vdso/gettimeofday.c:1:0: error: '-march=r3000' requires > '-mfp32' > > > > > > > > This is seen, for example, with the

RE: {standard input}:136: Error: number (0x9000000080000000) larger than 32 bits

2016-04-19 Thread Matthew Fortune
Maciej Rozycki writes: > On Mon, 18 Apr 2016, Maciej W. Rozycki wrote: > > > The thing is that to match some software's (such as ours) > > requirements an ISA override -- as a side effect -- relaxes ABI > > restrictions on certain operations. E.g. the DLI macro and its 64-bit > > immediate argu

RE: [PATCH 1/3] MIPS: Initial implementation of a VDSO

2015-09-28 Thread Matthew Fortune
Alex Smith writes: > > + > > + /* lapc is an alias to addiupc reg, - . > > +* > > +* We can't use addiupc because there is no label-label > > +* support for the addiupc reloc > > +*/ > > + __asm__("lapc %0, _start \n" > > +

RE: [PATCH resend] MIPS: Allow FPU emulator to use non-stack area.

2014-10-07 Thread Matthew Fortune
> > > > 4) The voice for doing any instruction emulation in kernel - it is not a > > MIPS business model to force customer to put details of all Coprocessor 2 > > instructions public. We provide an interface and the rest is a customer > > business. Besides that it is really painful to make a diffe

RE: [PATCH resend] MIPS: Allow FPU emulator to use non-stack area.

2014-10-07 Thread Matthew Fortune
> >> the out-of-line execution trick, but do it somewhere other than in > >> stack memory. > > How do you answer Andy Lutomirski's question about what happens when a > > signal handler interrupts execution while the program counter is > > pointing at this "out-of-line execution" trampoline? This se