From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x102e.google.com (mail-pj1-x102e.google.com [IPv6:2607:f8b0:4864:20::102e]) by sourceware.org (Postfix) with ESMTPS id EE2AD385801E for ; Fri, 6 May 2022 00:56:50 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org EE2AD385801E Received: by mail-pj1-x102e.google.com with SMTP id qe3-20020a17090b4f8300b001dc24e4da73so6608819pjb.1 for ; Thu, 05 May 2022 17:56:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=gvF5SnDLPr9HD3Yyxl8iKPmnXXcqhK3dP9JLBvf42eY=; b=TITah9dHyXJfdAuh+NJ7JuZbOWozMF2w3ChdiqVemLMThGLSeDMxnBvK4hv0GpF/XT LHIXjqiyR5FLIgQWndBRRJpinb7Fr71RKq4t9RQYNQb23uVt2FUR73eGFv6a1U446hrf Slclyq4Gya7z58EFmUVyg8V+gFi2wdaBtIBFpU2GOeqWDDNfxjc1iNwGtkrr01xCg05t 1xMaNh0UUm+nMUT64OMcyUDEoq3aL4Ureuc5akNY91/8OWdrKf/Lrxq1BujdjTgJ/lpP kHHFpc3PtgRoDdd5mCRstnl9xR8zgIVtOWEvWWCmFQpu5pg0IHnIH229sIBwi9NK3RZ8 V4ZQ== X-Gm-Message-State: AOAM533VhNfAC7ANkYAB+ZQbGFEpcyUCXaJFo3rzlU+1IlFNQnkWUhK8 qjSFZ6PM2wBPhBxJTizA0kMUfr83bk8= X-Google-Smtp-Source: ABdhPJx/QnQxaUAwlOk0cBgmcZgcO+U9NxlL4Wn9MnAXx5Iw59/t+sMQB6rHEI5/oVfEKO9Uyojr+A== X-Received: by 2002:a17:902:c404:b0:15e:9aa2:3abc with SMTP id k4-20020a170902c40400b0015e9aa23abcmr954418plk.172.1651798609684; Thu, 05 May 2022 17:56:49 -0700 (PDT) Received: from squeak.grove.modra.org ([2406:3400:51d:8cc0:dbf0:973e:74f1:a06e]) by smtp.gmail.com with ESMTPSA id kz2-20020a17090b210200b001cd4989febasm5900613pjb.6.2022.05.05.17.56.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 05 May 2022 17:56:48 -0700 (PDT) Received: by squeak.grove.modra.org (Postfix, from userid 1000) id 0DF231140AF9; Fri, 6 May 2022 10:26:46 +0930 (ACST) Date: Fri, 6 May 2022 10:26:46 +0930 From: Alan Modra To: Pedro Alves Cc: Hans-Peter Nilsson , binutils@sourceware.org Subject: Re: [PATCH] Don't define ARCH_cris for BFD64 Message-ID: References: <20220504075628.81292-1-luis.machado@arm.com> <88ada15d-c371-df10-368e-f1c9fb91c289@arm.com> <20220504143703.58AD620462@pchp3.se.axis.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Spam-Status: No, score=-3028.9 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, KAM_NUMSUBJECT, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: binutils@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Binutils mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2022 00:56:52 -0000 On Thu, May 05, 2022 at 12:11:29PM +0100, Pedro Alves wrote: > On 2022-05-04 23:37, Alan Modra via Binutils wrote: > > > OK, so this means we have two slightly different versions of cris > > support. Configured to support cris directly with --target or > > --enable-targets mentioning one of the cris tuples will always give > > you a 64-bit bfd. On a 32-bit host configured with > > --enable-targets=all you'll get a 32-bit bfd, and miss some support > > for explicitly choosing and displaying targets. (The #ifdef comments > > in config.bfd are used to generate targmatch.h, which gets included > > into targets.c.) > > I guess I don't understand the logic fully, and if you have the patience for me, I'd like > to understand it better. > > In the --enable-targets=all case with a 32-bit bfd, it seems counterintuitive to want to be able to choose > and display cris, if its bfd supposedly wants 64-bit, given want64=true. If bfd says cris wants > 64-bit bfd, and you have a 32-bit bfd, it seems weird to build it in 32-bit mode, and let users choose and > use it? As is often the case the truth is more complicated than it would appear on the surface. I think the cris support works fine with a 32-bit bfd. It's just that the cris testsuite has expressions that overflow 32 bits. gas/testsuite/gas/cris/shexpr-1.s has this expression: ((0x17<<23)+((0xfede4194/8192)<<4)+8) It evaluates to 0x0bff6f28 when calculating in 64 bits, but to 0x0b7f6f38 when calculating in 32 bits, because 0xfede4194 is −0x121be6c as a signed 32-bit number and the division is done using signed bfd_vma values. gas/testsuite/gas/cris/range-err-1.s has three uses of 0xffffffff that don't give the expected error when used in 8-bit and 16-bit fields if bfd_vma is 32 bits. That's because 0xffffffff is -1, and apparently -1 is OK for those fields. No doubt gas expression evaluation could be improved. eg. We could use C rules for whether constants are signed or unsigned, and track that through expression evaluation. The thing that give me pause in recommending that (or doing it myself) is that I suspect it might open up a can of worms assembling 64-bit target code, discovering lots of places where compiler output or user assembly isn't clean. A simple example is that 0xffffffffffffffff would no longer be equal to -1, and therefore might trigger field overflow errors. -- Alan Modra Australia Development Lab, IBM