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
