From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-f49.google.com (mail-wm1-f49.google.com [209.85.128.49]) by sourceware.org (Postfix) with ESMTPS id A0EE63856254 for ; Fri, 6 May 2022 09:00:05 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org A0EE63856254 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=palves.net Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-wm1-f49.google.com with SMTP id l62-20020a1c2541000000b0038e4570af2fso3968538wml.5 for ; Fri, 06 May 2022 02:00:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=QRjjtnHKD4Bqtd5fSrRAVhRgCXrDRzXkv8fHfN0I+cE=; b=7GqJ9uF8vpWpxR5wZ30xCKyIVeV9OWp0Bk9TEpHVYanybrZWrPobKaXCkAI5xviDhw kwizI3ZHYfJWI2T341qWvlCvj7MsWSfnqD2EBWMtitZUTpFKx4UHWlXRiY//GWbn65+2 MFqg31ATDfA5RRigKWvg5SCZ3Uo/K2x+kMBwizajd0GlcR8GsCie5f8Uhrll9g1wId/D T6Ut4nKYJcQF8DHlsTlu2rXK3pzY85N2bNojaR9LWpLklFLrvkuVR4rJLcnVfg4TDYaw Ok9LpEXiwpyPmA9RXlB8SRvZfnnnxt2mPTtwi3OJUDyaTPAWfwNegH5359y7PvUZ75Pw 62TA== X-Gm-Message-State: AOAM531VCxji+Y+RI/JyqgPqjk9WIO2DzmCd2wj8QVhj9afNr1HcNhNL qKntelIiLixGuQoPo/dSbpaYw+CyncY= X-Google-Smtp-Source: ABdhPJxYv3Crd8wHtIDG/jRWv06rmj1sEwH6BwKJaEwN+caMWfV4ye/7LCo1/8ou+gUw+WW4nHqfOw== X-Received: by 2002:a7b:c844:0:b0:38e:7c92:a9e3 with SMTP id c4-20020a7bc844000000b0038e7c92a9e3mr2246553wml.140.1651827604408; Fri, 06 May 2022 02:00:04 -0700 (PDT) Received: from ?IPV6:2001:8a0:f924:2600:209d:85e2:409e:8726? ([2001:8a0:f924:2600:209d:85e2:409e:8726]) by smtp.gmail.com with ESMTPSA id p6-20020a05600c358600b0039429bfebeasm3254663wmq.2.2022.05.06.02.00.02 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 06 May 2022 02:00:03 -0700 (PDT) Message-ID: <7fc3846e-6498-ee3b-efce-a28efe9ce519@palves.net> Date: Fri, 6 May 2022 10:00:01 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.1 Subject: 32-bit archs, want64=true, and gas integers (Re: [PATCH] Don't define ARCH_cris for BFD64) Content-Language: en-US To: Alan Modra Cc: Hans-Peter Nilsson , binutils@sourceware.org References: <20220504075628.81292-1-luis.machado@arm.com> <88ada15d-c371-df10-368e-f1c9fb91c289@arm.com> <20220504143703.58AD620462@pchp3.se.axis.com> From: Pedro Alves In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3.8 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, 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 09:00:07 -0000 Hi Alan, On 2022-05-06 01:56, Alan Modra wrote: > 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. I see. It wasn't just cris that contributed to my head scratching. We have these other cases like: powerpc-*-aix5.[01] | rs6000-*-aix5.[01]) targ_defvec=rs6000_xcoff_vec targ_selvecs="rs6000_xcoff64_aix_vec" want64=true ;; ... powerpc-*-aix[5-9]* | rs6000-*-aix[5-9]*) targ_cflags=-DAIX_WEAK_SUPPORT targ_defvec=rs6000_xcoff_vec targ_selvecs="rs6000_xcoff64_aix_vec" want64=true ;; ... spu-*-elf) targ_defvec=spu_elf32_vec want64=true ;; that say they want 64-bit bfd, but aren't wrapped in BFD64, nor do they have a targ64_selvecs. Makes me wonder whether they do that for a similar reason (gas), or whether they really need 64-bit vmas. It'd be great if these details / odd requirements were explained in comments so that people didn't have dig this stuff up. > > 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. > Looking at the "Numbers" chapter in the manual: https://sourceware.org/binutils/docs/as/Numbers.html we have: "Integers are numbers that would fit into an int in the C language. Bignums are integers, but they are stored in more than 32 bits." I note it says "more than 32 bits", not "32 bits or more". By my reading of the "Integers" and "Bignums" subsections, these integers are always signed. Maybe that should be explicitly said in the manual, instead of introducing signed vs unsigned numbers? And then, couldn't we make gas use int32_t for integers, and int64_t for Bignums (and clarify in the manual that "more than 32 bits" is exactly "64 bits"? IOW, use int64_t instead of bfd_vma in the expression evaluation stuff. That way, gas would be following what it documents, and 32-bit or 64-bit bfd would make no difference, and we'd get rid of a subtle host / --enable-64-bit-bfd -dependent behavior change for 32-bit ports. Pedro Alves