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 _______________________________________________ arm mailing list arm@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/arm
