RE: [RFC, PATCH, MIPS] Add support for O32 FPXX and program header based ABI information

[Matthew Fortune <Matthew dot Fortune at imgtec dot com>]

The GCC patch for this work has now been posted:

http://gcc.gnu.org/ml/gcc-patches/2014-05/msg00401.html

Should I address the current set of comments and re-post this patch
or should I wait for any further review?

Regards,
Matthew

> -----Original Message-----
> From: libc-alpha-owner@sourceware.org [mailto:libc-alpha-owner@sourceware.org] On Behalf
> Of Matthew Fortune
> Sent: 02 May 2014 10:09
> To: Will Newton; Andrew Pinski
> Cc: Joseph Myers (joseph@codesourcery.com); Richard Sandiford; Rich Fuhler;
> macro@codesourcery.com; libc-alpha@sourceware.org
> Subject: RE: [RFC, PATCH, MIPS] Add support for O32 FPXX and program header based ABI
> information
> 
> 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