On Sun, 21 Aug 2016, Slawa Olhovchenkov wrote:
On Sun, Aug 21, 2016 at 11:39:02PM +1000, Bruce Evans wrote:
On Sun, 21 Aug 2016, Slawa Olhovchenkov wrote:
I am remeber about platforms with missaligment trap when
accessing int16 by odd address. Now platforms like this do not exist
anymore?
i386 still exists, and it supports trapping on misalignement for at least
CPL 3 (not kernel CPL 0). IIRC, amd64 drops support for this.
Someone enable and support this? I am don't see.
May be PPC trap on this?
Alpha trap on this, but support of Alpha is droped.
It is a 1-line change in asm (or a little more in C with #includes) to
enable the trap:
%%%
#include <sys/types.h>
#include <machine/cpufunc.h>
#include <machine/psl.h>
int
main(void)
{
char ch[5];
write_eflags(read_eflags() | PSL_AC);
*(int *)&ch[0] = 0;
*(int *)&ch[1] = 1;
/* NOTREACHED */
}
%%%
This works on amd64 too after s/eflags/rflags.
It is a trillion-line change to fix the compilers and applications to not
do misaligned accesses :-). I only tried to use this ~25 years ago. Then
the most obvious compiler bug was generating 32-bit acccesses to assign
large but misaligned structs. If the compiler just generated calls to
memcpy(), that might work, but in practice libraries also assume alignment.
There are also endianness problems. The old version was even more broken
on big endian systems. The current version needs some magic to reverse
the memcpy() of the bits. We already depend on this for some 64-bit
syscalls like lseek().
Can you explain some more?
This is not transfer over network and don't read from external media.
Where is problem?
It is similar to a network transfer. It needs a protocol to pass values
to applications. Type puns are fragile even within a single compilation
unit.
Application ad kernel run with same byte order, not?
The application can do anything it wants, but has to translate if it uses
the kernel or a library written in another language.
Bruce
_______________________________________________
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
