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