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. -- markos
