On 09/29/2009 01:27 PM, Martin Guy wrote: > On 9/28/09, Daniel Kahn Gillmor <d...@fifthhorseman.net> wrote: >> However, it seems like we should still be filing bugs against packages >> which trigger alignment errors, no? > Absolutely.
i just filed a bug against libc6 (so this might be implicated in a lot of the bugs we're seeing): http://bugs.debian.org/548842 > An argument against enabling fixup is that it papers over bugs so they > remain undetected, while the fixup code is incredibly slow. A recent > example which should have run in under a second took three hours with > fixup enabled, which makes for programs that are silently and > invisibly much slower on ARM CPUs than usual. yeah, i don't think fixup is the right answer either, though it's tempting to use it in a production system. we really need to sort out where these problems come up. the example you mentioned (minutes vs. hours) i think was from my libvorbisidec question earlier. Interestingly, looking at that stuff i found that gcc placed code from the stack on odd addresses in armel, but placed them on 32-bit-aligned addresses on x86. That is, the following code causes alignment errors on armel because f gets placed on an odd address. it is on a 32-bit-aligned address on i386, fwict: char f[4]; void test(char* x, short z) { short* y = (short*)x; *y=z; } int main(int argc, const char* argv[]) { test(f,argc); return 0; } any idea why gcc would lay out the memory differently for armel than for i386? i haven't tried it on the old arm architecture. --dkg
signature.asc
Description: OpenPGP digital signature
