From owner-svn-src-all@freebsd.org Sun Aug 21 12:00:20 2016 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 915ADBC002D; Sun, 21 Aug 2016 12:00:20 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 55B1A1B26; Sun, 21 Aug 2016 12:00:20 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1bbRQG-00024K-C3; Sun, 21 Aug 2016 15:00:16 +0300 Date: Sun, 21 Aug 2016 15:00:16 +0300 From: Slawa Olhovchenkov To: Bruce Evans Cc: Ed Schouten , 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: <20160821120016.GZ8192@zxy.spb.ru> References: <201608210741.u7L7fBnN075023@repo.freebsd.org> <20160821105207.GS22212@zxy.spb.ru> <20160821210751.J2219@besplex.bde.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160821210751.J2219@besplex.bde.org> User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Aug 2016 12:00:20 -0000 On Sun, Aug 21, 2016 at 09:32:35PM +1000, Bruce Evans wrote: > On Sun, 21 Aug 2016, Slawa Olhovchenkov wrote: > > > On Sun, Aug 21, 2016 at 07:41:11AM +0000, Ed Schouten wrote: > >> ... > >> Log: > >> Use memcpy() to copy 64-bit timestamps into the syscall return values. > >> > >> On 32-bit platforms, our 64-bit timestamps need to be split up across > >> two registers. A simple assignment to td_retval[0] will cause the top 32 > >> bits to get lost. By using memcpy(), we will automatically either use 1 > >> or 2 registers depending on the size of register_t. > >> .. > >> Modified: head/sys/compat/cloudabi/cloudabi_clock.c > >> ============================================================================== > >> --- head/sys/compat/cloudabi/cloudabi_clock.c Sun Aug 21 07:28:38 2016 (r304554) > >> +++ head/sys/compat/cloudabi/cloudabi_clock.c Sun Aug 21 07:41:11 2016 (r304555) > >> @@ -117,7 +117,7 @@ cloudabi_sys_clock_res_get(struct thread > >> error = cloudabi_convert_timespec(&ts, &cts); > >> if (error != 0) > >> return (error); > >> - td->td_retval[0] = cts; > >> + memcpy(td->td_retval, &cts, sizeof(cts)); > >> return (0); > >> } > >> > >> @@ -129,6 +129,6 @@ cloudabi_sys_clock_time_get(struct threa > >> int error; > >> > >> error = cloudabi_clock_time_get(td, uap->clock_id, &ts); > >> - td->td_retval[0] = ts; > >> + memcpy(td->td_retval, &ts, sizeof(ts)); > >> return (error); > > > > Why do not use more simple solution: > > Because it doesn't work. > > > *(cloudabi_timestamp_t *)td->td_retval = cts; > > > > This is eliminate call to memcpy and allow compiler to use most > > effeicient way. > > memcpy() is the most efficient way (except for the kernel pessimization > of losing builtin memcpy with -ffreestanding 15 years ago and not bringing > it back). > *(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?