From: Markos Chandras <Markos.Chandras@imgtec.com>
To: Paul Burton <paul.burton@imgtec.com>,
Manuel Lauss <manuel.lauss@gmail.com>
Cc: Matthew Fortune <Matthew.Fortune@imgtec.com>,
Aaro Koskinen <aaro.koskinen@iki.fi>,
Linux-MIPS <linux-mips@linux-mips.org>,
Ralf Baechle <ralf@linux-mips.org>
Subject: Re: 3.18+: soft-float userland unusable due to .MIPS.abiflags patch
Date: Mon, 19 Jan 2015 09:15:58 +0000 [thread overview]
Message-ID: <54BCCB4E.5070005@imgtec.com> (raw)
In-Reply-To: <20150119053647.GV28594@NP-P-BURTON>
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@imgtec.com> wrote:
>>> Aaro Koskinen <aaro.koskinen@iki.fi> 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
next prev parent reply other threads:[~2015-01-19 9:16 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-16 17:59 3.18+: soft-float userland unusable due to .MIPS.abiflags patch Manuel Lauss
2015-01-16 18:06 ` Manuel Lauss
2015-01-16 19:12 ` Matthew Fortune
2015-01-16 20:01 ` Manuel Lauss
2015-01-16 20:04 ` Manuel Lauss
2015-01-16 20:36 ` Matthew Fortune
2015-01-17 16:38 ` Aaro Koskinen
2015-01-17 19:00 ` Matthew Fortune
2015-01-18 10:35 ` Manuel Lauss
2015-01-19 5:36 ` Paul Burton
2015-01-19 9:15 ` Markos Chandras [this message]
2015-01-21 0:00 ` Aaro Koskinen
2015-01-28 23:14 ` Aaro Koskinen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=54BCCB4E.5070005@imgtec.com \
--to=markos.chandras@imgtec.com \
--cc=Matthew.Fortune@imgtec.com \
--cc=aaro.koskinen@iki.fi \
--cc=linux-mips@linux-mips.org \
--cc=manuel.lauss@gmail.com \
--cc=paul.burton@imgtec.com \
--cc=ralf@linux-mips.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.