Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 21 Aug 2016 16:14:47 +0300
From:      Slawa Olhovchenkov <slw@zxy.spb.ru>
To:        Bruce Evans <brde@optusnet.com.au>
Cc:        Ed Schouten <ed@freebsd.org>, src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org
Subject:   Re: svn commit: r304555 - head/sys/compat/cloudabi
Message-ID:  <20160821131447.GA8192@zxy.spb.ru>
In-Reply-To: <20160821223255.K2478@besplex.bde.org>
References:  <201608210741.u7L7fBnN075023@repo.freebsd.org> <20160821105207.GS22212@zxy.spb.ru> <20160821210751.J2219@besplex.bde.org> <20160821120016.GZ8192@zxy.spb.ru> <20160821223255.K2478@besplex.bde.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160821131447.GA8192>