From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19179 invoked by alias); 18 Sep 2013 19:33:07 -0000 Mailing-List: contact libc-ports-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: libc-ports-owner@sourceware.org Received: (qmail 19160 invoked by uid 89); 18 Sep 2013 19:33:06 -0000 Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 18 Sep 2013 19:33:06 +0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_40,KHOP_THREADED,RDNS_NONE,SPF_HELO_FAIL autolearn=no version=3.3.2 X-Spam-User: qpsmtpd, 2 recipients X-HELO: relay1.mentorg.com Received: from svr-orw-fem-01.mgc.mentorg.com ([147.34.98.93]) by relay1.mentorg.com with esmtp id 1VMNUj-0005Sq-8n from joseph_myers@mentor.com ; Wed, 18 Sep 2013 12:33:01 -0700 Received: from SVR-IES-FEM-01.mgc.mentorg.com ([137.202.0.104]) by svr-orw-fem-01.mgc.mentorg.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 18 Sep 2013 12:33:00 -0700 Received: from digraph.polyomino.org.uk (137.202.0.76) by SVR-IES-FEM-01.mgc.mentorg.com (137.202.0.104) with Microsoft SMTP Server id 14.2.247.3; Wed, 18 Sep 2013 20:32:58 +0100 Received: from jsm28 (helo=localhost) by digraph.polyomino.org.uk with local-esmtp (Exim 4.76) (envelope-from ) id 1VMNUf-0002WA-Nd; Wed, 18 Sep 2013 19:32:57 +0000 Date: Wed, 18 Sep 2013 19:33:00 -0000 From: "Joseph S. Myers" To: CC: , , "Ryan S. Arnold" Subject: Re: e500 port: getcontext / setcontext / swapcontext In-Reply-To: <1379528954.4899.19.camel@spokane1.rchland.ibm.com> Message-ID: References: <1379528954.4899.19.camel@spokane1.rchland.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-SW-Source: 2013-09/txt/msg00102.txt.bz2 On Wed, 18 Sep 2013, Steven Munroe wrote: > Joseph I must really question the wisdom of merging the e500 into the > same source with the "classical" PPC32 code. > > The unified GPR/FPR set of the e500 impacts the ABI in many different > ways from the classic PPC32 soft-float or hard-float that I fear this > will be a constant source of misunderstanding and error in the future. > > I am much more comfortable keeping the e500 specific codes in different > source files and different parts of the tree. The design is detailed at . The function-calling ABI is identical to soft-float (the only case in which register high parts are used in argument passing / return is for e500-specific vector types). With this port version, the other aspects of the glibc ABI also match soft-float, so soft-float binaries can run with glibc built for e500; this avoids an unnecessary proliferation of ABI variants (requiring their own ABI test baselines etc.). The present getcontext / setcontext / swapcontext patch follows the same approach as the support in those functions for other optional features, with a macro __CONTEXT_ENABLE_E500 conditioning the e500-specific code, and in fact the substance of the e500 implementation is in a separate file context-e500.h in this case because that was the natural way to avoid code duplication in the swapcontext sources. -- Joseph S. Myers joseph@codesourcery.com