[fedora-arm] Broken sha512sum in coreutils

Gordan Bobic gordan at bobich.net
Sat Jan 8 09:54:02 UTC 2011


On 01/08/2011 02:49 AM, Chris Tyler wrote:
> On Fri, 2011-01-07 at 20:23 +0000, Andy Green wrote:
>> On 01/07/11 19:46, Somebody in the thread at some point said:
>>> ..snip..
>>>
>>>>>
>>>>> This must be a bug in sha512sum -- it shouldn't be affected by alignment.
>>>>
>>>> I am inclined to think it might be compiler related. Andy's package is
>>>> the same version as mine, his works, mine does not. The only thing that
>>>> is likely to be different is the build environment.
>>>
>>> That and the development board. You are using a sheevaplug.
>>> It is also likely that Andy's hardware does fixups for misaligned accesses.
>>
>> It's an NXP LPC3250, ARM926EJ-S.  I have no idea if the hardware is
>> handling the alignment issue but that would explain why everything is
>> exactly zero on that box's alignment error stats.  Searching the
>> datasheet for 'alignment' doesn't tell anything relevant.
>
> As I understant it, the 'A' profile for armv7 includes mandatory
> alignment fixup. Thus, if your CPU is armv7 it should do fixups in
> hardware -- with cost, but transparent. Most armv5 does not appear to do
> this.
>
> (Did the PHP 2.5*5 bug come up in this discussion? On a machine without
> hardware fixup, PHP prints 5.3114652946464E-315 as the answer for 2.5*5
> with 0 in /proc/cpu/alignment, but prints 5 when fixups are enabled.
> This seems to be a useful quick test).
>
> Related proposal: I think we should have the startup scripts
> set /proc/cpu/alignment to 3 (warn+fixup) by default in Fedora-ARM (we
> do this on the Koji builder image). I don't see a downside, and there's
> a definite upside on armv5 systems.

I see a number of downsides to this:

1) There is a performance hit.
2) It 's a workaround, not an actual fix. The code causing these 
problems should be fixed properly.

I would like to offer a counter-proposal - no package is accepted into 
Fedora (ARM?) until it stops generating misalignment warnings. That way 
there might actually be some effort toward getting things fixed rather 
than just glazing over the problem. From what I can see, relatively few 
things in the base distribution do actually trip the problem (one 
exception being DeviceKit-disks package that I mentioned earlier - will 
file a bugzilla on that later).

Additionally, in case things are missed in rudimentary pre-testing (and 
let's face it, they will be), alignment should be set to 1 (warn only), 
and these should be hooked into abrt so that bug reports can be 
auto-filed for all the broken packages (send the warnings, package 
version, and binary that caused the error). No packages showing up these 
should then be included in the next release until the problem is fixed.

I cannot stress enough how strongly I am against the concept of glazing 
over the problem by setting alignment to 2 or 3. That's a short-term 
workaround, not a fix. And if it gets set as default that will never 
change again and a lot of the motivation and drive for a proper fix will 
go away. Crap solutions for the sake of paths of least resistance are 
not the way forward and should not be encouraged. I hope I'm not alone 
in this view.

Gordan


More information about the arm mailing list