From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 130779 invoked by alias); 5 Jul 2017 05:37:19 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 107428 invoked by uid 89); 5 Jul 2017 05:36:11 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=3.3 required=5.0 tests=AWL,BAYES_00,FOREIGN_BODY,RCVD_IN_DNSWL_NONE,SPF_PASS,T_FILL_THIS_FORM_SHORT autolearn=no version=3.3.2 spammy=mitteilung, Mitteilung, geschftliche X-HELO: dedi548.your-server.de Received: from dedi548.your-server.de (HELO dedi548.your-server.de) (85.10.215.148) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 05 Jul 2017 05:36:08 +0000 Received: from [88.198.220.130] (helo=sslproxy01.your-server.de) by dedi548.your-server.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.85_2) (envelope-from ) id 1dScxt-00022J-BC; Wed, 05 Jul 2017 07:35:05 +0200 Received: from [82.135.62.35] (helo=mail.embedded-brains.de) by sslproxy01.your-server.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1dScxt-0004pK-1J; Wed, 05 Jul 2017 07:35:05 +0200 Received: from localhost (localhost.localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id 3B6432A004F; Wed, 5 Jul 2017 07:35:13 +0200 (CEST) Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id eiV01kxqDK2T; Wed, 5 Jul 2017 07:35:10 +0200 (CEST) Received: from localhost (localhost.localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id 68BCF2A1677; Wed, 5 Jul 2017 07:35:10 +0200 (CEST) Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id BqLxP-npUBGO; Wed, 5 Jul 2017 07:35:10 +0200 (CEST) Received: from [192.168.96.129] (unknown [192.168.96.129]) by mail.embedded-brains.de (Postfix) with ESMTPSA id 30B792A004F; Wed, 5 Jul 2017 07:35:10 +0200 (CEST) Subject: Re: [PATCH-v3] [SPARC] Add a workaround for the LEON3FT store-store errata To: Daniel Cederman , ebotcazou@adacore.com Cc: David Miller , gcc-patches@gcc.gnu.org, daniel@gaisler.com References: <20170627085530.12596-1-cederman@gaisler.com> <9253669.0heIyC41JS@polaris> <4c5c96e9-ea63-f6f7-1066-2a907db7c393@gaisler.com> <20170629.120524.1722371272567684822.davem@davemloft.net> <43816b02-62ed-5432-89bc-1afcbfe2bcf9@gaisler.com> From: Sebastian Huber Message-ID: Date: Wed, 05 Jul 2017 05:37:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <43816b02-62ed-5432-89bc-1afcbfe2bcf9@gaisler.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2017-07/txt/msg00236.txt.bz2 On 04/07/17 15:38, Daniel Cederman wrote: > > > On 2017-06-30 07:11, Sebastian Huber wrote: >> On 29/06/17 18:05, David Miller wrote: >> >>> From: Daniel Cederman >>> Date: Thu, 29 Jun 2017 17:15:43 +0200 >>> >>>>> I'm not thrilled with this, it's undocumented, the other workaround >>>>> don't have >>>>> it and I don't think that we really need it. >>>> The B2BST errata workaround requires more changes to assembler >>>> routines commonly used by operating systems, such as for example >>>> register window handling, than what the UT699 workaround needed. It >>>> would be nice to have a way to only enable these modification when the >>>> -mfix- flag is used. The alternative would be to provide a define >>>> directly on the compiler command line in conjunction with -mfix >>>> flag. But if more changes are required later on it would be good to >>>> have the define more closely tied to the flag to minimize the number >>>> of changes to Makefiles and etc. >>> Personally, I have never seen compiler based CPP defines as ever being >>> useful for tailoring OS assembler code. Ever. >>> >>> In most cases you will want to support several families of CPUs and >>> therefore sort out the individual cpu support assembler routines >>> internally in the kernel sources. >> >> This depends on the operating system you use. For some embedded=20 >> systems where the application and the operating system are one=20 >> executable it is quite common to use compiler provided defines in=20 >> assembly code. >> >> For example: >> >> https://sourceware.org/git/gitweb.cgi?p=3Dnewlib-cygwin.git;a=3Dblob;f= =3Dnewlib/libc/machine/arm/memcpy-armv7a.S;h=3Dcd7962e075a30cb90ec073d77b17= 7c3536429b9b;hb=3DHEAD=20 >> >> >> For a software development kit, the run-time libraries are built for=20 >> a set of multilibs. Each assembler file may use multilib specific=20 >> compiler defines, e.g. floating point unit present or not, errata XYZ=20 >> present or not, etc. >> > > We can drop the define if necessary, but we would like to keep the two=20 > flags. Would that be OK to apply? > If I read the GRLIB-TN-0009 correctly, then we have to adjust the=20 context switch, interrupt processing and window management code in=20 RTEMS. So, we definitely need this define. Since this errata affects actually the GRLIB, which is used in many=20 products, should we really start adding -mfix-some-processor options?=20 The GRLIB affected by this errata may be used in custom designs as well.=20 I suggest to simply add a -mfix-leon3ft-b2bst option which enables the workaround and adds a builtin define #define __FIX_LEON3FT_B2BST The documentation for this option should mention this and also reference=20 the GRLIB-TN-0009 and maybe the affected known processors. --=20 Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.huber@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine gesch=C3=A4ftliche Mitteilung im Sinne des EHUG.