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. b) Fix the broken case - I doubt it will be too challenging to fix up the implementation to allow the soft-float ABIFLAGS + no ABIFLAGS combination. c) Apply Markos' updated patch (with the references to r6 removed). I'll leave it to others to decide which approach is best. Thanks, Matthew
