> >  > I've set the compiler up to do this as well.  We need to write kernel code
> >  > to fault these sequences on chips that can do so.
> >
> > I can take a look at this -- the question is:
> >
> > * Do we want the kernel to optionally provide fixups for
> >   unaligned loads on such systems?
> 
> If we did, would we implement the ARM semantics (which ARM hackers would
> be expecting) or the VAX semantics (which naive C programmers would be
> expecting)?

Naive C programmers need to learn to write better code!
(we no longer guarantee that 0 at address 0 for VAX compatibility)

Fixing it in a trap handler will just make things run so slowly...

However the arm hacker might want to make use of the misaligned loads
to optimise some (horrid) function.
Maybe they should be allowed on a per-process basis, with a user controlled
on/off setting.

Mind you I got a hint from someone I know that some future arm chips
might be able to do misaligned transfers....  Dunno what is actually planned.
> 
> > * Do we want the kernel to be verbose about the unaligned
> >   load?
> 
> I don't see why it should do any more than send a SIGBUS.  The core dump
> will have all the necessary information in it, and we already have
> kern.logsigexit for controlling whether SIGBUS gets logged.
Agreed - does the core dump give you enough info?
(ie is the reason for the trap detectable?)

    David