On 09/29/2009 01:27 PM, Martin Guy wrote:
> On 9/28/09, Daniel Kahn Gillmor <dkg@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
Attachment:
signature.asc
Description: OpenPGP digital signature