From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 69438 invoked by alias); 21 Sep 2018 12:41:09 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 69417 invoked by uid 89); 21 Sep 2018 12:41:09 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: =?ISO-8859-1?Q?No, score=-4.0 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,HTML_MESSAGE,SPF_PASS autolearn=ham version=3.3.2 spammy=HTo:U*joel, H*Ad:U*rth, instructions.=c2, H*c:alternative?= X-HELO: mail-vs1-f65.google.com Received: from mail-vs1-f65.google.com (HELO mail-vs1-f65.google.com) (209.85.217.65) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 21 Sep 2018 12:41:07 +0000 Received: by mail-vs1-f65.google.com with SMTP id x198-v6so4627731vsx.12; Fri, 21 Sep 2018 05:41:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Sv93aiCxVdOlKKSDmisxGHcrwUcBbXfH91VwDQPrxFc=; b=euOgrOrKPoqf/GU/LpXADmqaR6e7/87IvqOpr9selueW8ssMa58pzZZ5xmIG9kWYnN 6ilKzofG6SlDLC0dmcCYYHHN/GreVbKhIpBRQzoB8DUmjYs+5a5szkKNDxVDQ2D3s6bg k79QTSHiJpREe+YeIVLRyrI02gY5WRjs/hFVt+/WAbB9zeUUrxAfn4MArfuQeUrUkF48 dSFn0iLxkbdbVI8mmmEiFjriClENBXe+of3XRwoOVdYrYblO8+g5C+WoJh1BzRT56mtz o6kJ0SDMKMN+uoYpkf6xK+zx38iBVvV71bt7WqIUPcLj50ueN+mP38/VWVEbWmHxMjAv isxg== MIME-Version: 1.0 Received: by 2002:ab0:740c:0:0:0:0:0 with HTTP; Fri, 21 Sep 2018 05:40:45 -0700 (PDT) In-Reply-To: References: <20180821143823.16985-1-shorne@gmail.com> <20180908213515.GN4594@lianli.shorne-pla.net> <20180918095234.GP4594@lianli.shorne-pla.net> <20b65fc3-5bbb-6e77-f598-4582204ee0e5@redhat.com> From: Stafford Horne Date: Fri, 21 Sep 2018 12:41:00 -0000 Message-ID: Subject: Re: [PATCH 0/4] OpenRISC binutils updates and new relocs To: joel@rtems.org Cc: Nick Clifton , Richard Henderson , Binutils , GDB patches , Openrisc Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2018-09/txt/msg00751.txt.bz2 Hi Joel, On Tue, Sep 18, 2018 at 2:07 PM, Joel Sherrill wrote: > > > On Tue, Sep 18, 2018, 6:56 AM Nick Clifton wrote: > >> >> > As Richard mentioned we don't handle this. >> > >> > We have cases like this right now as well, i.e. binaries generated with >> `l.mul` >> > or `l.div` instructions will link fine into an executable that assume >> those >> > instrunctions should be emulated. That doesn't throw an error and I >> don't think >> > it has been a problem. >> >> OK, well it is your target, so if you are OK with this then so be it. >> I would recommend however thinking about a solution for the future, >> should the >> openRISC architecture gain more variants. My suggestion would be to make >> use >> of ELF notes, as has been done with other ports. >> > > Is there a way to avoid these instructions with GCC? As a general rule, > for RTEMS we assume the code is properly generated for the target CPU and > don't emulate missing instructions. > > Also for these cases, is there a flag implicitly set by GCC based on CPU > specific flags to let assembly code.know not to use them. > > And are there mulilibs which do and do not use them? > To answer all, yes. There were some recent openrisc mailing list discussions on this. I have decided to add a new multilib flag -mclass1 -mclass2 (default is mclass1 instructions only) to stop gcc from using any class2 instructions. > In the deeply embedded space, we assume the tools and user can generate > code which doesn't need emulation traps. There is some responsibility on > the toolchain to.make it possible. > Yes, We did think about this when we were writing the new port, but we are only just implementing it now. Check the GCC docs in the next patch version I submit. -Stafford