linux-kernel - Re: RFC: remove the "tile" architecture from glibc

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 9 Mar 2018 16:31:36 +0000
From:   Joseph Myers <joseph@...esourcery.com>
To:     John Paul Adrian Glaubitz <glaubitz@...sik.fu-berlin.de>
CC:     Arnd Bergmann <arnd@...db.de>, Helmut Grohne <helmut@...divi.de>,
        GNU C Library <libc-alpha@...rceware.org>,
        linux-arch <linux-arch@...r.kernel.org>, <metcalf@...m.mit.edu>,
        Henrik Grindal Bakken <hgb@....uio.no>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: RFC: remove the "tile" architecture from glibc

On Thu, 8 Mar 2018, John Paul Adrian Glaubitz wrote:

> I have personally invested a lot of work into the SH port over the
> past three years in Debian and I was involved fixing many bugs
> and as a result, the port is quite usable. It would be really
> disappointing to see it being removed all of a sudden :(.

Note that SH glibc test results need some work - there are a large number 
of failures listed at <https://sourceware.org/glibc/wiki/Release/2.27#SH>.  
Probably most could be addressed with the NaN fixes I outlined at 
<https://sourceware.org/ml/libc-alpha/2018-02/msg00440.html> - but that 
does of course need someone to do the work to implement that in GCC and 
glibc.  (The stdlib/tst-tininess failure is stranger; SH manuals don't 
seem very specific on this, but the existing setting was definitely 
determined by testing on hardware.  SH experts with access to a range of 
different hardware may be needed to advise on what different hardware does 
or is supposed to do in this regard.)

The glibc port whose test results cause me the most concern that it's 
effectively unmaintained and should be considered for obsoletion is 
MicroBlaze - the results 
<https://sourceware.org/glibc/wiki/Release/2.27#MicroBlaze> are clearly a 
big mess (not something where one fix would probably resolve most failures 
as on SH) and there's no sign of activity to sort them out (nor has there 
been such activity for a long time).

-- 
Joseph S. Myers
joseph@...esourcery.com