Re: [linuxsh-dev] Re: bad alignment fixup

[David W. <dw...@in...>]

pr...@pa... said:
>  no.  we have the code for the few insns actually used by the kernel,
> and it can go away as soon as someone convinced DaveM having the
> network stack use unaligned accesses is silly. 

Not going to happen, mainly because having the network stack use unaligned
access _isn't_ silly.

Unaligned accesses in the network stack are a _very_ uncommon case, but a 
case which we have be able to deal with nonetheless. Having checks for 
alignment in all the networking fast paths would be insane.

What we're doing here is very similar to what we do in __copy_user() - 
optimising the common case and letting the CPU raise an exception so we can 
fix up the rarer cases. Doing the check in software is silly when the CPU 
can do it for you instead.


pr...@pa... said:
>  Do it correctly or don't do it at all.  "We emulate all unaligned
> memory accesses except 3 or 4 we didn't bother with" isn't a sensible
> rule.

It's correct, or certainly getting there. It's not _complete_ but I'm sure
someone will contribute the missing insns, even if _we_ don't actually get 
round to it.

pr...@pa... said:
>  which makes using a syscall return value constant confusing.

It doesn't confuse me. Standard error numbers are used _internally_ 
throughout the kernel, even where they're not actually being returned to 
userspace.


pr...@pa... said:
>  address error doesn't necessarily mean unaligned access.

P485 of the SH-3/SH-3E/SH3-DSP Programming Manual says:

"Address errors are caused by instruction fetches and by data reads or
writes. Fetching an instruction from an odd address or fetching an
instruction from an on-chip peripheral register causes an instruction fetch
address error. Accessing word data from other than a word boundary,
accessing longword data from other than a longword boundary, and accessing
an on-chip peripheral register 8-bit space by longword cause a read or write
address error."

OK, so PC could be the address of an on-chip peripheral register. Sick, but
vaguely possible. I'd still say that such is a 'should never happen' 
event, but I have no particular attachment to that comment so if it really 
offends you it can go.

Are there other causes of address error in SH-[45]?

Perhaps we also need to explicitly check for the case of a wrongly-sized 
access to the on-chip peripheral space. Simply refusing to fix up any 
exceptions on accesses to on-chip peripheral space should be sufficient.

--
dwmw2