This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
RE: [RFC, PATCH, MIPS] Add support for O32 FPXX and program header based ABI information
- From: Matthew Fortune <Matthew dot Fortune at imgtec dot com>
- To: Will Newton <will dot newton at linaro dot org>, Andrew Pinski <pinskia at gmail dot com>
- Cc: "Joseph Myers (joseph at codesourcery dot com)" <joseph at codesourcery dot com>, Richard Sandiford <rdsandiford at googlemail dot com>, Rich Fuhler <Rich dot Fuhler at imgtec dot com>, "macro at codesourcery dot com" <macro at codesourcery dot com>, "libc-alpha at sourceware dot org" <libc-alpha at sourceware dot org>
- Date: Fri, 2 May 2014 09:09:22 +0000
- Subject: RE: [RFC, PATCH, MIPS] Add support for O32 FPXX and program header based ABI information
- Authentication-results: sourceware.org; auth=none
- References: <6D39441BF12EF246A7ABCE6654B0235351E3D7 at LEMAIL01 dot le dot imgtec dot org> <CANu=DmjUz8p0iTAqXn0FdHD-EtedXZ=G6KDjTzzGGyEPxRgMgQ at mail dot gmail dot com> <CA+=Sn1kpgJaYZ2tq40nDC_e2f0EZAsqiz3Nsf0NqcOg519MV9g at mail dot gmail dot com> <CANu=DmjB93Cnyd2w96U_PQaBam8Snm6FFZq5RwsZFWkTQwTLFQ at mail dot gmail dot com>
Will Newton <will.newton@linaro.org> writes:
> On 2 May 2014 09:18, Andrew Pinski <pinskia@gmail.com> wrote:
> > On Fri, May 2, 2014 at 1:11 AM, Will Newton <will.newton@linaro.org>
> wrote:
> >> On 1 May 2014 22:48, Matthew Fortune <Matthew.Fortune@imgtec.com>
> wrote:
> >>
... snip
> Val_GNU_MIPS_ABI_FP_DOUBLE)
> >>> + switch_frmode_to (0);
> >>> +
> >>> + asm volatile ("cfc1 %0,$1\n": "=r"(status));
> >>
> >> I would be inclined to make these inline asm statements into a
> >> function with a descriptive name, and potentially the status values
> >> could usefully be named too.
Good call. We tried to introduce more meaningful pseudo-instructions for this
feature but concluded that just using CTC1 was best.
> >>
> >>> + if ((status == 0 && req_abi == Val_GNU_MIPS_ABI_FP_64)
> >>> + || (status == 1 && req_abi ==
> Val_GNU_MIPS_ABI_FP_DOUBLE))
> >>> + _dl_signal_error (0, map->l_name, NULL, "Unable to set
> FP mode");
> >>
> >> Under what circumstances can this error occur?
> >
> > The hardware does not support the requested mode.
Yes-ish. Theoretically the kernel should not be advertising the UFR HWCAP
if one of the modes is not supported. UFR is only supported in hardware if
both modes exist but may well be implemented in trap-and-emulate on
MIPS32r2 and MIPS64 cores. If UFR is not supported nor emulated then the
CTC1 will lead to a crash. If the hardware and/or emulation doesn't work
correctly then this is a safety check to try and catch such failures. The
worst thing that could happen with this feature is a mode switch silently
failing; tracking down the bug would be horrendous.
> Maybe "Hardware does not support mode %s" would be a more helpful
> message in this case.
Since at this point of the code the hardware 'should' have been able to
enter the mode... I guess "Hardware failed to set mode %s".
regards,
Matthew