[fedora-arm] Broken sha512sum in coreutils

[Andy Green]

On 01/07/11 18:45, Somebody in the thread at some point said:

>> With this issue, a correct structure in a typedef or a struct with
>> correct alignment padding turns to crap because the structure pointed to
>> is not on a u32 boundary for example.
>
> I see. But shouldn't the compiler be taking care of that? -malign?

For most code the compiler or malloc is ultimately always making the 
pointer and takes care about its alignment so you never see such symptoms.

However take for example structures that are coming into a buffer as 
part of a byte stream, it is uncontrolled how many bytes have come in, 
but you know there is a struct in the buffer n bytes from the start of 
your buffer.  Like -->

struct mystruct *p = (struct mystruct *)&buffer[n];

On x86 this code is always OK, although it may run faster or slower 
depending on alignment.

On ARM, when n is 0, or 4 etc then all is well.  When n & 3 is nonzero, 
and so p & 3 is nonzero, all multibyte members in the pointed-to struct 
are misaligned and give you garbage data on dereference unless the 
kernel sees the fault and fixes it up.  And I mean complete trash, made 
up of pieces of the other members next to it.

The compiler can't help you.

When I wrote the radiotap parser for the kernel mac80211 layer, it 
required some extremely defensive code to access all struct members via 
bytewise access and not typed pointer dereference for this reason.

> counters haven't increased at all, my guess is that it all happened last
> night when I was building/testing dietlibc stuff. I'll test that
> hypothesis when the new kernel is built.

Fine but what has happened with your sha512sum then?  Is it the case 
that somehow the shared libc in memory is the dietlibc one?  Maybe if 
you reboot without touching anything that touches dietlibc you won't see 
this issue again and the whole thing is a painful lesson to leave 
dietlibc the hell alone ^^

-Andy