On Thu, Jan 25, 2001 at 03:05:36PM +0000, Michael Nonweiler wrote:
> At 14:31 25/01/01 +0000, Nicholas Clark wrote:
> >On Thu, Jan 25, 2001 at 12:48:10PM +0000, Michael Nonweiler wrote:
> > > I am worried about remaining problems with unaligned accesses to word and
> > > short data.
> >
> >Have you experimented yet with a conventional ARM Linux setup where you
> >recompile a kernel with the alignment trap handler turned on?
> >You shuld be able casts in C to manufacture unaligned pointers to trigger
> >the traps (IIRC it reports usage in /proc somewhere) and see if it correctly
> >fixes up the results of unaligned pointer reads and writes.
> >If the alignment trap handler works (in user space?) what classes of remaining
> >problems are you worried about?
>
> I am worried that the alignment trap handler doesn't work efficiently
> enough, so I want to know how much it is used in a real systems. It is
> _very_ slow, (100s of cycles?) so while I accept it fixes exactly the
> problem I'm worried about, I want to know how frequently (both statically
> and dynamically) it is used.
>
> Your comments suggest you have never had a problem with this?
>
> I believe existing ARM Linux setups make more use of the alignment trap
> than absolutely necessary, because they allow the compiler increase
> alignment assumptions by optimising accesses to structures that contain
> only bytes. This is why I want to base my experiments on a non-standard
> system.
As the alignment FAQ you quoted says, it is ANSI compliant for the
compiler environment to specify this implementation. I don't think that
much code that I've met falls foul of it (the 2.2 kernel's Apple HFS filing
system and the dos fs tools being the only 2 I've encountered, I think. And
I really should submit the patches I made for both to their maintainers)
For about 2 years I've been using ARM Linux on an Acorn RiscPC with almost
every kernel built with the alignment trap handler turned off (which I
believe is Russell's default config for the RiscPC). To my knowledge there
has never been a problem on my hardware with this using my Ethernet card.
I compiled a kernel recently with the handler turned on, and after running
the machine for a while the stats in /proc showed that the handler had not
been called at all. However, I believe that although the Ethernet card was
on and configured, there was no cable plugged into it, so this may reflect
on the results I saw.
I don't know anything about the implication of hardware differences on a
Netwinder. Acorn machines have an Acorn specific hardware expansion bus,
so the range of cards and hence drivers used is limited. Hence the
drivers specific hardware available for the Acorn may be written with ARM
ABI alignment in mind. I'm also not sure if the bus is limited to byte at a
transfer.
Russell King has also said to me that the code generated by gcc to access 16
bit quantities has changed. If I remember correctly it used to use a 2 byte
misaligned LDR and then mask out the 16 unneeded bits. Technically an
unaligned load, but it knew what it was doing. Now it uses 2 bytes loads and
a logical OR. I was asking about making the alignment handler optionally
generate SIGBUS to trap problems, and he said that older binaries compiled
with the word loads would trigger, even thought they were not actually
about to fall foul of non-alignment. My system was entirely ELF when I tested
the trap handler, so I may have seen no traps because all my binaries were
compiled with a recent compiler.
I think that this is the sum total of what I know.
Nicholas Clark
_______________________________________________
http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm
Please visit the above address for information on this list.
