Hi, On Mon, Jan 19, 2015 at 09:15:58AM +0000, Markos Chandras wrote: > On 01/19/2015 05:36 AM, Paul Burton wrote: > > On Sun, Jan 18, 2015 at 11:35:31AM +0100, Manuel Lauss wrote: > >> On Sat, Jan 17, 2015 at 8:00 PM, Matthew Fortune > >> <Matthew.Fortune@xxxxxxxxxx> wrote: > >>> Aaro Koskinen <aaro.koskinen@xxxxxx> writes: > >>>> On Fri, Jan 16, 2015 at 08:36:12PM +0000, Matthew Fortune wrote: > >>>>> You are right that it is the .MIPS.abiflags patch that is causing your > >>>>> trouble. For a long time I had to put a restriction in the ABI plan > >>>>> that soft-float binaries without an ABIFLAGS pheader could not be > >>>>> linked against soft-float binaries with an ABIFLAGS pheader. We have > >>>>> since found a way to relax that restriction without reducing the > >>>>> effectiveness of the new compatibility checks. I would need to check > >>>>> the code in the kernel but I suspect that is the issue. Markos has > >>>>> done a significant update to this piece of code which he posted > >>>>> earlier today. That updated version should allow the combination of > >>>>> soft-float without ABIFLAGS and soft-float with ABIFLAGS. > >>>> > >>>> Are you referring to the series with 70 patches? I think a fix that > >>>> passes stable kernel rules is needed. > >>> > >>> Yes it was just one patch though for this issue: > >>> [PATCH RFC v2 68/70] MIPS: kernel: elf: Improve the overall ABI and FPU > >>> mode checks > >>> > >>> I wasn't trying to suggest how to fix the existing code just explaining > >>> how it came to be and what has been done about it for next release. > >>> (I'm not a kernel developer I'm just interested as I did most of the > >>> design work for the new ABI extensions.) > >>> > >>> I guess there are three options: > >>> a) revert the patch - That would remove the new ABI safety measures from > >>> 3.19 which is a shame given it has MSA support in it (I think anyway). > >>> equally given that the new prctl FPU mode options did not make 3.19 > >>> then I suppose it doesn't lose too much either as the two features > >>> go hand in hand to some extent. > >> > >> I favor this one. I don't know how many systems with MSA are in the wild, > >> and if there are any, I'm sure they're using some mti/imgtec-supplied kernel > >> anyway. Another thing I noticed last time is that companies shipping MIPS > >> products rarely upgrade their toolchains, so I'm sure the ABI safety measures > >> can wait for another release, but then function with all configurations > >> in the wild. > >> > >> Manuel > > > > An alternative would be the patch I just submitted, which makes the mode > > checks conditional upon CONFIG_MIPS_O32_FP64_SUPPORT: > > > > http://marc.info/?l=linux-mips&m=142164553017027&w=2 > > > > Assuming this fixes your problem, and I believe it should, it would > > avoid the churn of reverting the patch & readding the modified logic > > again later. > > > > Thanks, > > Paul > > > There is also this patch from James for 3.19 final > > http://patchwork.linux-mips.org/patch/8932/ > > so with these two patches we should be good for 3.19. This patch is also needed to run hard-float O32 userspace compiled using binutils 2.25 with 64-bit 3.19-rc5 (otherwise kernel fails to start init). So please ensure that these patches end up to next 3.19-rc ASAP! I have to say this O32 "ABI extension" seems to be very poorly introduced. For softfloat, the current 2.25 binutils broke _all_ existing GCC releases. And for hardfloat, newly compiled userspace appears to be unusable with the current kernel mainline... :-( A.
