Date: Sun, 21 Aug 2016 23:00:24 +1000 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Slawa Olhovchenkov <slw@zxy.spb.ru> Cc: Bruce Evans <brde@optusnet.com.au>, 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: <20160821223255.K2478@besplex.bde.org> In-Reply-To: <20160821120016.GZ8192@zxy.spb.ru> References: <201608210741.u7L7fBnN075023@repo.freebsd.org> <20160821105207.GS22212@zxy.spb.ru> <20160821210751.J2219@besplex.bde.org> <20160821120016.GZ8192@zxy.spb.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
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(). 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(). 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?20160821223255.K2478>