From owner-svn-src-head@FreeBSD.ORG Fri Mar 13 15:23:42 2015 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D3259D7A; Fri, 13 Mar 2015 15:23:42 +0000 (UTC) Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) (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 B563089B; Fri, 13 Mar 2015 15:23:42 +0000 (UTC) Received: from comporellon.tachypleus.net (polaris.tachypleus.net [75.101.50.44]) (authenticated bits=0) by d.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id t2DFNdK7031331 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 13 Mar 2015 08:23:40 -0700 Message-ID: <550300FB.4040000@freebsd.org> Date: Fri, 13 Mar 2015 08:23:39 -0700 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Konstantin Belousov Subject: Re: svn commit: r279937 - in head/sys/powerpc: include powerpc References: <201503122115.t2CLFdmi026986@svn.freebsd.org> <20150312212234.GS2379@kib.kiev.ua> <55020547.7050102@freebsd.org> <20150312213530.GT2379@kib.kiev.ua> <5502094D.5090001@freebsd.org> <20150313084702.GV2379@kib.kiev.ua> In-Reply-To: <20150313084702.GV2379@kib.kiev.ua> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-CAuth: UmFuZG9tSVa5CyIz9vNhrmyabYfbBvT8pXOGwPKO4ycv+fwAoPPtC7zsKocOByxmzTJvVZJE5LWIw/wQjksbUDxFt8DfWeKXCL2pMJy5amQ= X-Sonic-ID: C;chch7ZTJ5BGUdb5YxQPdhw== M;dGh47ZTJ5BGUdb5YxQPdhw== X-Spam-Flag: No X-Sonic-Spam-Details: 0.0/5.0 by cerberusd Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2015 15:23:42 -0000 On 03/13/15 01:47, Konstantin Belousov wrote: > On Thu, Mar 12, 2015 at 02:46:53PM -0700, Nathan Whitehorn wrote: >> On 03/12/15 14:35, Konstantin Belousov wrote: >>> On Thu, Mar 12, 2015 at 02:29:43PM -0700, Nathan Whitehorn wrote: >>>> On 03/12/15 14:22, Konstantin Belousov wrote: >>>>> On Thu, Mar 12, 2015 at 09:15:39PM +0000, Nathan Whitehorn wrote: >>>>>> Author: nwhitehorn >>>>>> Date: Thu Mar 12 21:15:38 2015 >>>>>> New Revision: 279937 >>>>>> URL: https://svnweb.freebsd.org/changeset/base/279937 >>>>>> >>>>>> Log: >>>>>> Provide VSX context in ucontext(3) API. >>>>>> >>>>>> Modified: >>>>>> head/sys/powerpc/include/ucontext.h >>>>>> head/sys/powerpc/powerpc/exec_machdep.c >>>>>> >>>>>> Modified: head/sys/powerpc/include/ucontext.h >>>>>> ============================================================================== >>>>>> --- head/sys/powerpc/include/ucontext.h Thu Mar 12 20:14:48 2015 (r279936) >>>>>> +++ head/sys/powerpc/include/ucontext.h Thu Mar 12 21:15:38 2015 (r279937) >>>>>> @@ -46,6 +46,7 @@ typedef struct __mcontext { >>>>>> uint32_t mc_av[2]; >>>>>> register_t mc_frame[42]; >>>>>> uint64_t mc_fpreg[33]; >>>>>> + uint64_t mc_vsxfpreg[32]; /* low-order half of VSR0-31 */ >>>>>> } mcontext_t __aligned(16); >>>>>> >>>>>> #if defined(_KERNEL) && defined(__powerpc64__) >>>>>> @@ -60,6 +61,7 @@ typedef struct __mcontext32 { >>>>>> uint32_t mc_av[2]; >>>>>> uint32_t mc_frame[42]; >>>>>> uint64_t mc_fpreg[33]; >>>>>> + uint64_t mc_vsxfpreg[32]; /* low-order half of VSR0-31 */ >>>>>> } mcontext32_t __aligned(16); >>>>>> #endif >>>>> It looks as if you broken the ABI compatibility by the change. Am I wrong ? >>>>> >>>> That is correct. It's a tier-2 platform and -CURRENT, so I'm not sure >>>> it's worth the compatibility shims. I'm happy to add them if you think >>>> otherwise. >>> You are main maintainer of PowerPC port, IMO, so it is your decision. >>> >>> Note that 'this is current' argument is not applicable, since the change >>> also breaks stable/* binaries. >>> >>> I do understand the argument of PowerPC being tier 2 architecture, but this >>> makes me sad. Anyway, it is yours. For x86, I have to introduce >>> getcontextx(3) mechanism. >>> >> This is a good point. I'll try to fix it. Is my understanding of how >> this works correct? >> >> 1. Provide a sysarch() for the extended FPU state. >> 2. Implement getcontextx() in the C library to fill extra properties if >> required. >> 3. Store state for signal trampoline in variable-sized stack area > 4. Implement __getcontextx_size() and __fillcontextx2() for use > in the deferred signal delivery while libthr is in critical section, > see lib/libthr/thread/thr_sig.c:check_deferred_signal(). OK. >> Implementation of (2) seems to rely on having spare members in ucontext, >> which PowerPC unfortunately does not have. Is there a way around that? > Indeed, this is very unfortunate. > > My concern is that typical application allocating ucontext_t on stack or > by mallocing it, would get silent memory corruption after the extension > of mcontext_t. It seems indeed that ABI breakage cannot be completely > avoided, but it could be significantly reduced IMO. Is it true that > mc_avec is only valid when _MC_AV_VALID bit is set ? That is correct. > If yes, we can introduce another mcontext flag, say _MC_XSTATE_VALID, > which is mutually exclusive with the _MC_AC_VALID. The new flag > indicates that there is external data, and the data is pointed to by > some word placed in the previous mc_avec file, say mc_avec[0]. The > altivec registers file content is moved into that external data area as > well. Providing the external area size in mc_avec[1] allows to extend > that block in the future-compatible manner. > > This way, applications which use ucontext_t and which are not aware about > VSX, get the expected behaviour, possibly without seeing altivec. I.e. > in typical case, we do not get random memory corruption. OK, I guess that's reasonable. I'll think about this some and try to get some code written in the next few days. > Meantime, I have a question. I looked at the powerpc/include/ucontex.h > and tried to match it with the PowerISA specs 2.06 and 2.07. From what I > understand, mc_fpreg corresponds to the floating-point registers file, > mc_avec and mc_av to the 'Vector Facility Registers'. But I fail to see > what would match the > + uint64_t mc_vsxfpreg[32]; /* low-order half of VSR0-31 */ > file. The 7.2.1 Vector-Scalar Registers says 'Sixty-four 128-bit VSRs > are provided'. > The 64 128-bit registers are a superset of the existing registers. Registers 33-64 are just the Altivec registers, with no changes. Registers 1-32 are the normal floating point registers, but widened to 128 bits from 64. What I had tried to do was to keep the layout of the bottom part of the structure unchanged for compatibility by storing only the extra half of registers 1-32 in a separate area. In particular, I wanted to keep the FP registers readable in a consecutive way. -Nathan