[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: alignment errors on armel: what to do?

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):


> 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;

int main(int argc, const char* argv[]) {
  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.


Attachment: signature.asc
Description: OpenPGP digital signature

Reply to: