svn commit: r304555 - head/sys/compat/cloudabi

Bruce Evans brde at optusnet.com.au
Sun Aug 21 13:39:22 UTC 2016


On Sun, 21 Aug 2016, Slawa Olhovchenkov wrote:

> On Sun, Aug 21, 2016 at 11:00:24PM +1000, Bruce Evans wrote:
>
>> On Sun, 21 Aug 2016, Slawa Olhovchenkov wrote:
>>
>>> On Sun, Aug 21, 2016 at 09:32:35PM +1000, Bruce Evans wrote:
>>> ...
>>>> *(foo_t *)asks for alignment bugs.  We have already fixed lots of these
>>>> bugs for copying struct timevals in places like ping.c.  Compilers warn
>>>> about misalignment when certain warnings are enabled, but only on arches
>>>> where misalignment is more than a pessimization.  There is no reason why
>>>> td_retval would be always aligned on these arches.  Alignment of 64-bit
>>>> types on 32-bit arches is usually so unimportant that even int32_t is
>>>> not required to be aligned by the ABI, and there is no point in
>>>> aligning td_retval specially unless you also do it for a large fraction
>>>> of 64-bit integers in the kernel, and there are negative points for
>>>> doing that.
>>>
>>> For eliminate aligment bugs need to replace all assigment more then 1
>>> bytes to *td_retval by memcpy?
>>
>> The copying must be of size 1 or 2 ints unless you are making even larger
>> type puns than now.  1 int is obviously safe to just assign, and 2 ints
>> should use memcpy().
>
> Why?

If it has size not 1 * sizeof(int) or 2 * sizeof(int) or is not an integer,
than it is had to assign to a 2-byte array and might need more careful
packing just to memcpy() it.

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

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

Bruce


More information about the svn-src-all mailing list