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

[Slawa Olhovchenkov]

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? I am remeber about platforms with missaligment trap when
accessing int16 by odd address. Now platforms like this do not exist
anymore?

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

> Hmm, lseek() uses different magic.  Instead of the memcpy(), we assign
> to tdu_off in td_uretoff.  td_retval is really td_uretoff.tdu_retval
> obfuscated like this for compatibilty.  This is slightly better than
> the memcpy() since it makes tdu_off and also tdu_retval 64-bit aligned
> if that is required for off_t.  The same magic still occurs in userland.
> On normal 32-bit arches, the 2 integers arrive in 2 registers that have
> to be combined in the right order to give a 64-bit value.  The magic is
> just that things are arranged so that no code is needed to rearrange the
> registers in the usual case where the application uses a similar ABI to
> the kernel.  Not the same ABI, since the application might be 32 bits
> and the kernel 64 bits.  This requires lots of conversions, but none for
> register order for at least x86.
> 
> Bruce