Hi, On Wed, Jan 21, 2015 at 02:00:33AM +0200, Aaro Koskinen wrote: > 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). Seems to be still missing in 3.19-rc6... A.
